Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
How APIs Have Taken Over the World (Even Though Your Mom's Never Heard of Them)34:20 with Jason Lengstorf
t's no secret that the Internet has fundamentally changed the way the world works. We have access to *all* of the information in almost any format we can imagine. We can cheat at a pub quiz using Wikipedia on our phones; we can have our refrigerator text us when it's time to buy more milk; we can have a flying drone send realtime video from a hundred feet in the air. But what most people don't know is that the Internet is being powered in large part by APIs. Your Instagram photos use the Foursquare API to tag their location. Best Buy uses Twilio's API to power a global call center. Virtually *everyone* is using Amazon Web Services APIs to make their sites faster and more scalable. In this talk, you'll see just how pervasive APIs are in today's connected world, how your company can leverage APIs to provide more value for your customers, and how releasing an API for your company's data can help encourage more people to use your company's services.
Okay. 0:01 So today I want to talk about APIS's, and how they've become pervasive. 0:01 I mean they've been pervasive, but I feel like now more than ever 0:07 it's extraordinarily common for APIS's to be 0:10 involved in almost everything that we do. 0:14 So if you think of pretty much any app, it's most likely got an API involved. 0:18 If you think about Instagram. 0:27 Instagram is using the Facebook Places API for location data, 0:28 formerly FourSquare before they made that switch and everything got terrible. 0:33 There's the, you know, a lot of apps 0:37 that deal with restaurants are using Yelp for reviews. 0:40 A lot of, almost everybody is using Amazon Web 0:45 Services for scaling and keeping things fast and distributed. 0:48 And it's just starting to seem like nobody builds an app all on its own. 0:54 Very few apps are standalone now. 1:00 And you know for me, I'm fully on board with this. 1:02 I think that it's great, for a lot of 1:07 reasons, which is what we're here to talk about today. 1:09 But before we get into that, let's talk about me a little bit. 1:13 So I founded a company called Copter Labs. 1:17 It's a small digital marketing agency. 1:19 I've been doing this for a little over a 1:22 decade and I've written a few books on web development. 1:24 And that's as much as I'm gonna say about myself because I hate it 1:29 when people get up on stage and talk for 25 minutes about what they do. 1:31 So let's talk a little bit about what happened and 1:35 how we got to this point of apps all using APIs. 1:38 So, I think the first thing that really happened was apps need more features. 1:43 When you talk about what's there and how to be competitive in the market. 1:53 Almost all apps need to have more and more features. 1:58 They need to have location base, they need to have an 2:03 SMS feature, they need to do push notifications, they need to be 2:06 mapped, they need to have anything you can think of, it's 2:09 probably need to be in the app in order to stay competitive. 2:13 The exception to this is single-service apps. 2:16 Things that only do one thing and do it really well. 2:19 But the catch to that is that those apps 2:24 tend to be the services that power other apps. 2:26 We also need to be fast. 2:30 One of the key differentiators between being the 2:32 first app to the market and being a 2:35 copy of an original app is the speed with which we can get it pushed out. 2:36 And time is very, very limited. 2:42 There's only so many people on the team, there's only so many 2:45 hours on the day to build these features and to push things out. 2:47 So, you run into things where you're building 2:50 an app and your core service is here. 2:53 But in order to get the features out, in order 2:56 to get everything running, you have to have this service, 2:58 and this service, and this service all running and each 3:01 one of those is really a full time job to build. 3:04 So you run up against this wall where you need the features, you need it to 3:07 be fast, but there's only so many hours to build these things and get them out. 3:11 And just as a disclaimer for anybody who came here looking for code. 3:16 This is literally no code in this presentation, this is more of a business 3:20 presentation, I won't hold it against you if you want to walk out now. 3:22 Another thing is that this stuff is hard. 3:28 When we're talking about building an SMS 3:29 delivery service, that is not a simple task. 3:32 That's not something you can build in a couple days and just have it run reliably. 3:34 Same thing with email delivery or you know all these little things that from a, 3:38 from a feature perspective, they're very, very small parts of the overall offering. 3:44 But they're very complicated things to do well. 3:49 So how do we solve this problem really 3:52 the solution is that it's probably already done. 3:57 Most of the services that you need to build a feature already exist. 4:02 For e-mail delivery we can use Mandrill, for SMS deliver we can use 4:06 Twilio, for real time we can use Pusher or any of the Pusher clones. 4:08 And it's all already out there and in many cases, it's free, 4:13 if you look at the Facebook API, you can use that for a lot of different things. 4:20 Doesn't cost you anything. 4:24 You can use the Foursquare API for location, it doesn't cost you anything. 4:25 Google Maps, the Twitter API all these are, 4:29 are services that you can integrate into your 4:32 app that don't add any actual overhead and 4:34 the ones that are paid are relatively cheap. 4:37 Things like Twlio, Amazon web services, Heroku, Stripe. 4:41 They all charge, but in the grand scheme of things it's relatively cheap. 4:46 And it's invisible to the user. 4:52 When you use Twilio, when you use, you know, Mandrill, when you use Amazon 4:54 web services, nobody who's using your app 5:01 actually knows that that's what you're doing. 5:04 They just see that the app works. 5:06 So, in terms of, of the impact on 5:08 your business, there's literally no negative impact by using 5:11 one of those services in terms of, of 5:15 the credibility or how seriously somebody will take it. 5:17 So, using web services in my opinion is a really, 5:22 really good idea in terms of rapidly getting to market. 5:26 And, creating something, that's very, very useful, some of 5:29 the benefits are, it's already built, it's already been done. 5:34 If you need an SMS service you don't need to go out 5:37 and figure out how that works I don't actually even know where to 5:40 start, but I know that I can go to Twilio and pay 5:43 next to nothing and its already working and a few lines of code. 5:46 These sources are actively maintained, so if you build and sms 5:50 server in house, your if you build your own massively skilled server. 5:55 Those are really high maintains tasks, those 6:00 services are gonna required constant updates, rules are 6:03 gonna change, technology is gonna move forward, you're 6:06 gonna have to keep those up to day. 6:08 The benefit of using a service, is this 6:10 company is build around maintaining and improving that service. 6:12 So the work is, excuse me, the work is done for you. 6:15 Which you know, the things that suck the life out of a business tend to 6:20 be those maintenance tasks that keep you from focusing on mission critical things. 6:27 And so if you can leverage a service that's gonna 6:31 solve that problem for you of maintaining a non-mission critical service. 6:33 You're really, you're putting a lot of money 6:37 back in your pocket, and again it's cheaper. 6:40 Twilio, okay so the example I have here, Twilio costs, 6:45 three quarters of a penny per text message that you send. 6:50 So if your app is based on sending text messages to people. 6:53 And you send a million messages a month, which is a lot. 6:56 It'll cost you $90,000 a year. 7:01 Which seems like a lot of money but when you consider that 7:03 the average salary for a senior developer is right around the $100,000 mark. 7:06 And that something doing that kind of volume is 7:11 probably going to require more than just one person. 7:13 You're actually saving a shit load of money. 7:16 It frees up your resources for mission critical tasks. 7:20 When you, you know, like I said, when you're not maintaining the auxiliary 7:23 services, you can actually focus on the things that are important to the business. 7:26 The things that are gonna bring you more revenue. 7:29 The things that are gonna move your app to the next level and 7:32 improve your offering, as opposed to 7:35 improving the infrastructure that supports your offering. 7:37 Which all leads to the result that we want, 7:41 which is swimming in a big pool of money. 7:45 Now 7:47 there are definitely some risks involved when you are 7:49 talking about a you know, using a third party service. 7:51 I think they're all pretty limited risks. 7:56 And I'll talk about why. 7:57 The first one is that it is out of your control. 8:00 So there is the possibility that the service will 8:02 have down time, that they will go into emergency maintenance. 8:04 You know, shit happens. 8:07 But really, if you think about it, if you're trying to 8:10 maintain that service internally, your internal service can also go down. 8:13 You can also have emergency maintenance. 8:18 And really from like a, likelihood that it's gonna get fixed quickly standpoint. 8:20 Your business, needing to reallocate developer resources, 8:26 to get over and fix that service, 8:29 versus the company that just panicked because 8:31 their entire revenue model just went down. 8:32 They're probably gonna fix it faster. 8:35 There's always the chance that it goes the way of Google Reader, rest in peace. 8:39 Tech companies are always being purchased. 8:42 They're changing what they offer. 8:45 They're just plain running out of money and folding. 8:47 And that's a very real risk because when you tie yourself to a third party 8:50 service, especially if it's for a core feature, 8:54 if it shuts down, you're in big trouble. 8:57 However, if you use your best judgement 9:01 when you're making decisions on which services 9:03 to integrate with, you do have the 9:05 ability to choose companies that have enormous support. 9:08 You know, a good indication of whether or not a service 9:12 is gonna be around is typically, you know, who are their clients? 9:14 Do they have big clients? 9:17 If you're looking for, you know, something like [UNKNOWN]. 9:18 It's powering Pinterest. 9:21 It's powering a bunch of companies that we've 9:23 all heard of and that have massive funding. 9:26 So the likelihood of them running out of money is pretty low. 9:29 If something else happens you're usually gonna get a lot of notice. 9:33 Oh we've been purchased we gonna sunset this service. 9:36 You know, come up with a plan and pivot there. 9:40 And so, you know, it, it really does just kinda 9:45 using a service within your app gives you so much leeway 9:49 to, do things quickly, to avoid all these hassles and headaches of 9:52 you know, having to build and maintain the stuff and actively keep it rolling. 9:59 Which is why I think that, you know, in terms of, from 10:03 a business standpoint, this is really one of the best things that 10:05 you can do, is find strategic ways to integrate other services, and 10:08 let those power your business rather than trying to reinvent the wheel. 10:14 And now the second part of this, I think, is where I really feel that the 10:19 opportunity lies for a lot of businesses, which is, you have a unique offering. 10:25 You have things that you can build, that you're building right now. 10:31 But whatever your services and your app, you probably got something 10:34 unique, which is why you're in business in the first place. 10:37 And there's probably a good chance that that server 10:40 is useful outside of the scope of where you've 10:44 imagine it to be. 10:49 It could be the way that you're collecting data, 10:51 it could be the way that you're processing data. 10:53 It could be that you just solve an issue that's pretty common. 10:55 And you're offering that as a service, and other 10:59 businesses could stand to benefit from using your service. 11:02 If they integrate your unique offering, you have then become 11:07 a service that solves a problem for them, which allows you 11:09 then to become more pervasive in the industry without even, 11:12 you know, you get more adoption by solving other people's problems. 11:16 Four square is another example of this. 11:21 Where Four Square is an app that probably would have folded if it wasn't 11:23 for the fact that the API had such a strangle hold on the industry. 11:26 Everybody used it, and that really kept them afloat 11:30 for a long time, it's still kinda keeping it afloat. 11:32 You can always benefit from seeing other use cases. 11:37 Letting other people use your service or data is a great way 11:40 to see where else that data can be used, which it gives you 11:44 the opportunity to reassess what you're doing and how you're doing it; and 11:48 where it could, theoretically, be a new revenue stream, a new business model. 11:52 And this is you know a great way to 11:57 rapidly see what else is possible using your data rather 12:00 than having to do a bunch of expensive in house 12:04 testing and secondary offerings and all those sorts of things. 12:05 A few big examples of this that I've found are 12:10 like Flickr, for example, used to be an online gaming service. 12:14 It was a game that had a photo-sharing component. 12:17 And they saw that when people were using the service that the 12:20 photo sharing was far more popular than the game, so they just 12:23 shut down everything that wasn't working and kept the photo service which 12:27 made it extraordinarily valuable and led 12:29 to long term success that's still continuing. 12:31 You know, Facebook, we all know, was a Hot or Not clone. 12:36 Facemash I think it was called. 12:39 And it grew through different iterations as they saw who was using it and 12:41 it's not the most dominate force on the internet or one of them at least. 12:45 Instagram was a originally a check in app, kinda like Foursquare 12:49 and the photo component become more popular they saw an opportunity there 12:52 based on the way people were using it, and they moved over 12:56 in, and just offered the photos, and they now dominate that space. 12:58 So again, it really, none of those were services that were opened up. 13:03 But it's, the concept is the same. 13:07 If you can see how people using, are using the data, it allows you 13:11 to get a better idea of where it's actually useful or where it's most useful. 13:14 And then spin that into a better 13:19 offering, a refined offering, or an entirely different 13:22 offering that can make you more money 13:24 and improve the success of your company overall. 13:28 Another thing that I truly believe is that 13:32 businesses live and die by the developer community. 13:34 If you are running a business, and it's 13:37 online, I really steadfastly believe that if you can 13:40 get developers to adopt your service, that it's 13:44 gonna have a much, much better chance of success. 13:49 The reason for that being that, you know, developers 13:51 get to make the decisions when they're building these apps. 13:53 What gets integrated? 13:56 What gets used? 13:56 What do we want to connect to? 13:57 What do we want to link to? 13:59 And then if there's an API available that they can use, what gets used? 14:00 And again, Four Square is a great example of this because they did a great job of 14:05 aggregating place data and they did it so well 14:09 that nobody wanted to bother and try to compete. 14:12 And as a result, Foursquare got adopted by the developer community. 14:15 And I think that's why it outlasted apps like Goala. 14:18 Is because it was so well received by the 14:23 developer community, and so pervasive in apps that, they, you 14:25 know, they, they could keep the app afloat without really 14:27 needing they didn't really need the app to be used. 14:30 You know, the fact that it was popular just kinda helped. 14:34 There's also a lot of revenue potential in an API. 14:40 You have the ability to monetize. 14:44 You can look at Twilio, you can look 14:47 at Stripe, you can look at Mandrill or Syngrid? 14:50 All they're doing is solving one simple problem. 14:54 And by opening that up and solving that problem 14:57 for other people, they are creating this huge profit potential. 14:59 Twilio is an excellent example actually, of a 15:05 company that never even bothered with the product. 15:07 They saw a problem, they knew they could solve it. 15:09 And they knew that there was no possible way for them to release 15:12 a product that would be valuable enough to solve enough problems to actually work. 15:15 So, instead they said, we're just gonna solve the 15:20 problem and we're gonna give it to people to use. 15:22 And they found that there are so many 15:25 different uses for this, the SMS and now they've 15:28 got MMS, voice, you know, everything that you 15:31 can think of as phones, Toyota finally does it. 15:33 And the different applications you know, Best 15:36 Buy is powering a call center with it. 15:38 They're actually tons of call centers powered by Twlio mms marketing, SMS 15:39 marketing, the ability to check in through an SMS app, 15:45 post updates you know, all that kind of stuff is all powered through that. 15:50 Urban airship does a push notification on IOS 15:56 which is kind of a similar thing Stripe, 15:58 they don't have a product, they just have the API's so that you can accept payment. 16:01 And all these services are great examples of 16:05 companies that saw that they could solve a 16:08 problem and they could solve it well, but 16:10 that it didn't make sense for the consumer market. 16:12 And so if you've got a great idea, but 16:14 you're not quite sure how to make it into a 16:17 product, it could just be that you've got an 16:18 idea that will turn into lots of great product ideas. 16:20 So you can just package that down into solving that 16:24 problem, hand it to developers, and say, go build cool shit. 16:28 And, by letting them do that you can create this huge profit 16:32 potential, and these, enormous margins based 16:37 on, you know, solving a great problem. 16:40 So if you're going to be releasing an API there's a few considerations. 16:43 Things that I found will help boost adoption, things 16:47 that will help people get the hang of it. 16:50 And I think the most important one is to remember to drink your own Kool-Aid. 16:53 If you do, release an API, try to make it 16:59 something that you can use internally have your own, product. 17:02 Use the API the way anybody else's product would use the API. 17:05 Obviously if you've got your special sauce it 17:09 doesn't need to be gated that sort of thing. 17:11 You can always do that but I would still try to 17:13 keep it within the API maybe just don't expose those methods publicly. 17:15 The reason for this is that when you 17:20 create a API it's going to require maintenance. 17:22 You're gonna need to upgrade, you're gonna need to add features, and if 17:24 you got an internal set of tools that you're using that have these features. 17:28 And then you've got your external API that's 17:31 public facing and you have to upgrade them both. 17:33 You can guess which one's gonna suffer and that's not really a good thing 17:36 when you're talking about trying to release 17:40 something that's gonna help build your business. 17:42 If you're API is lagging behind you're feature set, because you only 17:44 have enough time and resources to allocate to fixing one at a time. 17:47 Then you're going to lose that faith of the developer community. 17:51 You're going to run into issues where you know, compatibility just 17:54 doesn't quite make sense because you're moving in two different directions. 17:58 And you know, the fact of the matter is that when you create an 18:02 API that you can use internally, you'll spot more issues with it as well. 18:05 And you'll be able to quickly release patches and 18:09 maintain it, and that all just rolls out into good 18:12 will in the developer community, because you are consistently 18:15 improving and updating and offering them new things to do. 18:18 I really recommend using rest API's. 18:24 It's very, very common. 18:26 It's easy for developers to understand, especially 18:28 if they've ever worked with another API. 18:30 Must APIs right now are restful and you know, 18:32 if you run into an API that's not, it's 18:36 like an XML parsing feed, you're just like, oh 18:37 my God, I don't want to deal with this. 18:39 And so you know, it's definitely something that's worth looking into and doing right. 18:41 It's again, adoption is key when you're talking about one of these services. 18:47 If people don't wanna use it, if it's hard to use, it's 18:51 not gonna get adopted, and you're gonna run into a lot of walls. 18:54 Make sure that you are following the rules. 18:58 If you're doing a restful API you know, 19:00 there is a, there's a whole manifesto that's written 19:02 and I've totally blanked on the guys name, 19:05 I apologize to him, and everyone on the room. 19:07 But there's a research people, if you do a Google search for rest API's one of 19:10 the first things that'll gonna come up is a thesis that was written on what rest is. 19:14 And there's a lot of different rules involved 19:20 in rest, but if you follow the big ones, 19:21 you're gonna find that your service is easier to 19:24 maintain, it's easier for people to use, it's easier 19:26 to document, and, as it grows, you're not 19:28 gonna run into these wired walls where you've built 19:31 it this way but now you need to add 19:34 this feature and it doesn't fit into this architecture. 19:35 Everything ends up being a logical endpoint on it's own so you can just pull 19:38 that data and use your own business logic to aggregate and process that. 19:42 So it'll make your life easier, it'll make developer's lives 19:48 easier and it will increase the longevity of your API. 19:50 Don't cut corners when you're building an API. 19:55 It doesn't matter if it's faster, you absolutely will regret it. 20:00 If you build an API and you take shortcuts and you do the 20:03 fast thing to get something out right now, it's okay as long as it's 20:06 a very, very, very high priority to fix those cut corners in the 20:11 short term because it's, it's gonna come back and bite you in the ass. 20:14 Probably internally, definitely externally, if you, if 20:17 you don't follow along with those rules. 20:20 Buying the good docs, definitely spend the time on documentation. 20:24 Internally, this is be huge, you won't have everybody emailing 20:29 the chief architecture, the API asking them how to get things. 20:34 He'll be able to actually work, or she'll [UNKNOWN] those sexes. 20:37 But by taking the taking 20:40 the, the need for a single person to demystify the API and eliminating the 20:45 need for people to do a lot of trial 20:51 error, you will hugely boost your internal productivity, external productivity. 20:52 Everybody will feel a lot better about using the API 20:57 and again, it's just going to go so far for adoption. 21:01 Really good examples of adoption would be Strike, Twilio, Heroku has 21:05 great getting started guides on how to get up on their service. 21:10 And then in the non-service realm, you know, 21:13 PHP, for all that it lacks, has excellent 21:16 documentation, you can find anything you need on 21:19 the PHP docs, jQuery's another one with excellent documentation. 21:21 So, you know, one of the reasons I think that PHP is one of the most popular 21:27 languages out there still is because of how easy its documentation is to use. 21:32 So for a beginner, if they were trying to get dig into something like Node. 21:37 I mean I know Node has been recently working 21:41 their docs recently but like, Node docs originally, were hell. 21:43 You had to remember what version you were using, and then you had 21:46 to figure how to do all the compatibility, and the docs weren't clear. 21:48 It wasn't easy to find things, and as a 21:51 result it became this, like, nerd club where only 21:53 the smartest developers can use it and everybody else 21:56 was kinda like, I think maybe I'll use PHP. 21:59 Because I can, you know, find information about that. 22:02 The same with WordPress. 22:06 You know, I think part of the reason it's so pervasive is because of the resources 22:08 that are available to start working with it, 22:11 as opposed to something like Ghost or Concrete. 22:14 They've all got docs, but WordPress just has far and away more comprehensive docs. 22:16 Another thing that's very, very important is to trust your developer community. 22:23 Don't be weird about usage. 22:27 Don't date things, don't arbitrarily shut 22:28 people down, don't impose awkward usage limits. 22:32 You know, if it's something you want people 22:37 to pay for, that's fine, you can set 22:39 the gate and say, after the so many 22:41 request, you have to pay per month, that's fine. 22:42 But don't just decide that only your company gets to use the full API 22:45 unless there's something very, very, very specific 22:51 that is the core of your revenue model. 22:53 The trust that developers are going to build cool things with it. 22:57 And if you neuter their ability to use the API, you are going to eliminate a lot 23:00 of cool things they could have done with 23:06 it and you're gonna cause a lot of frustration. 23:08 So, you know, focus on really opening it up, 23:10 being transparent, trust that they're gonna do cool things. 23:13 You know, nobody's gonna come in and 23:16 duplicate your business model using your service. 23:18 That would be a really dumb thing to do because you could 23:20 just shut them down and you would, you know, negate all their work. 23:23 So people are gonna use it for things that 23:26 are in different verticals or just in different usage. 23:27 Something that's gonna be you know, using some more 23:32 data, but not in direct competition or if it's in 23:34 direct competition it'll kinda feed back into you because they'll 23:37 be paying you for using your service to create competition. 23:39 So it's still you know, money. 23:42 And then you know, try to be very clear about what your usage guidelines are. 23:46 Be very black and white about it. 23:51 Nobody likes a black box. 23:53 You know, the, the App store is great example 23:56 of a very frustrating kind of service where you put 23:58 things in, and there's not really a clear guideline for 24:01 why things get rejected or why things get shut down. 24:04 So, you've got fair use rules about what's 24:07 gonna, you know make something okay or not okay. 24:10 It needs to be across the board, it needs to be uniformly 24:13 enforced and it needs to be written out in such a way 24:16 that people can understand it so that when their app gets shuts 24:19 down and they go why the hell did my app get shut down. 24:22 You click to a part of the agreement that says, you know, we 24:24 don't allow this because of this or just we simply don't allow this. 24:28 So that it's not an arbitrary decision. 24:32 You're not being the man behind the curtain being like no. 24:34 That kind of honesty and transparency is going to go a long 24:38 way toward bolstering goodwill and reminding 24:41 people that you are on their side. 24:44 This is honestly, it's a pretty short talk. 24:49 Because I don't think that there's a lot of 24:51 like, mundane detail to get in to on this stuff. 24:53 I think that we just want to cover the basics you know? 24:57 So use third-party services, you can add more features faster. 24:59 You will save time and money. 25:07 And the trade offs are pretty negligible and then if 25:10 it makes sense for your business which in a lot 25:14 of cases if you know, if you've got some kind 25:16 of a public facing product there is a case for this. 25:18 You can increase adoption of your service. 25:23 You can identify new use cases which can help you grow your business or morph your 25:25 business or pivot, to use a buzzword, into 25:29 something that's more profitable and has more longevity. 25:31 And you can create bonus revenue by doing something you were going to do anyway. 25:35 And the result of all of this, again, is swimming in a big pile of money. 25:39 So that's, that's pretty much all that I've got on this. 25:46 I wanted to leave a little bit of time for questions and 25:49 a little bit of time for you know, a slightly longer break. 25:52 Does anybody have any questions about any of the stuff that I've been talking about? 25:55 >> What was the [INAUDIBLE]. 26:00 >> I think, you know, FourSquare was, if, even if 26:10 they weren't, they had the illusion of being there first. 26:13 And they did a really good job of allowing users to create data for them. 26:15 So you could add a place to their, their database and, and it would. 26:20 You know, grow things really well. 26:24 So they did a great job of cross indexing that, targeting it, making sure 26:25 that everything in their database was accurate and easy to use through the API. 26:29 So when you created an app or service but needed to integrate foursquare. 26:35 It would be accurate, it would be quick. 26:40 Well not quick. 26:42 Foursquare always had issues with being a little bit sluggish. 26:43 But the information that came out of it and the value added was always good. 26:45 You didn't have a lot of issues with it giving you 26:50 the wrong location or returning zero locations when there were some. 26:53 And I think that, that was a, you know, that went 26:58 a long way toward making it something that people wanted to use. 26:59 It was a true value added to a service as 27:02 opposed to an annoying third party thing that sometimes worked. 27:05 Yeah. 27:08 >> What's a new API you're excited about 27:12 and what's one you'll never work with again? 27:14 >> Ooh, a new API that I'm excited about. 27:17 I don't know exactly how new it is. 27:21 I mean, it's probably three years old or maybe even a little bit older. 27:25 But, Stripe? 27:28 If you've ever dealt with payment platform it's a nightmare. 27:30 I mean, eCommerce on the web is, is like 27:35 just it's one of those things that when you 27:38 get told your project has eCommerce, it doesn't matter 27:40 how many times you've done it, you're probably like goddammit. 27:42 So for me having Stripe available it made it so 27:44 quick and easy to do a lot of the things that were a huge pain in the ass before. 27:51 And it takes all these burdens off of you like trying to do you know, protecting 27:56 user information and doing recurring transfers, setting up 28:01 subscriptions, things like that, which is, like enormously valuable. 28:04 For an API that I will never work with again. 28:10 I mean never say never because there's always a client. 28:12 But, I hate a lot of the API's that are setup for some of the email 28:15 list management services, Infusionsoft is a good example 28:19 of one that just drives me totally bonkers. 28:22 I don't know if they changed this recently. 28:25 But the last time I checked like their core product won't 28:27 work in Google Chrome, you have to open up Firefox to use Infusion Soft's service 28:32 which is an indication of how much they don't understand that developer's 28:37 are gonna be using this product to you know, to work for their clients. 28:42 And when I tried last, one of the big things in Infusionsoft 28:48 is the ability to tag users when they come into the list. 28:51 And the API doesn't provide a clear way to do that. 28:55 So you kinda get stuck, like, trying to hack around and add 28:58 people, like, kinda through a backdoor, 29:01 and work around Infusionsoft's own internal processes. 29:03 Just to do something that should be a core feature, because that's one of 29:06 the main ways that they monetize this 29:10 service is through this tagging and automated funnels. 29:12 So that's you know, basically any API that I've 29:16 ever used, what they do there as their business model. 29:19 If it is somehow hobbled in the API where 29:24 I can't perform core functions I, you've made an enemy. 29:28 You know that whole, you've made a powerful enemy today. 29:32 That's how I feel every time that they, that 29:34 I get an API that doesn't do those things. 29:36 Did I see another question over here? 29:39 Yeah, what's up? 29:40 >> I have a very 29:40 small site 29:46 project that 29:51 [INAUDIBLE]. 29:58 >> I mean there's always the risk when you start a business that's based on another 30:03 business that they just decide well, we hate all of our developers now. 30:09 You know Twitter's a good example. 30:15 They just kinda like shut down a lot of the API and 30:16 blackboxed it so that you have to use their proprietary widgets and. 30:20 It's, you know it's, it was a, it was 30:23 a business decision that didn't make sense to me. 30:25 I'm sure they had internal reasons for it with Netflix I'm sure it has something to 30:28 do with all these weird dealings and their, 30:31 it's, you know, net neutrality and all that stuff. 30:33 There's probably something that they're doing that's for whatever reason 30:35 it's beneficial not to have other people using the service 30:39 But in that case, I mean, sometimes you just get 30:44 hosed unless there's something else that can do similar things. 30:48 Cause I don't know how you're using the API but, you know, you, if you can find 30:53 another database of, of movies and shows that 30:56 you can, you know, leverage or something like that. 30:59 It could be possible to just switch your service and see how that goes. 31:01 You know, the, like Instagram just did with 31:06 the Facebook place's API to you know, lukewarm results. 31:08 But it sometimes, just shit happens. 31:13 [LAUGH] >> [INAUDIBLE]. 31:17 I just want to say [INAUDIBLE] I use a bunch of API's 31:20 for my app wanna be Netflix and that kinda sucked and made. 31:24 >> Yeah. 31:27 >> I was grandfathered in because in 2012 I think they announced 31:27 they were no longer gonna accept new developers for their API. 31:32 I was all right, good. 31:36 I got it at ground zero [UNKNOWN] just recently 31:38 they announced that as of November there's been a return to [UNKNOWN]. 31:44 >> Oh, that sucks. 31:48 >> So I wanted to comment on that so talk to 31:49 you later, but then my other question is what sort of service. 31:52 >> [INAUDIBLE] 31:58 I mean, most of them have a status blog that you just can follow. 32:04 And a lot of them will just release that as a service, up or down. 32:09 I personally don't. 32:13 You mean, for a person API? 32:15 [INAUDIBLE]. 32:17 Six or seven APIs. 32:19 So checking the status of each one would be. 32:20 I didn't know if there was like a dashboard type of service like this. 32:23 >> Well I mean there's, like, are my sites up would actually be useful. 32:26 You could just hit whatever the, the public API end point is. 32:30 And if it returns, you know, a 500, then you know it's down. 32:33 So that could be a way to kind of hack it. 32:36 Other than that, though, I mean, you could, you 32:39 could probably whip something together pretty quickly that would just 32:41 be, like, a cron set to run every so 32:43 minute, every so many minutes that runs a rudimentary request. 32:46 And if any of them go wrong, you can just hit yourself with an email 32:50 or with a message that says, you know, you've got a problem with this service. 32:52 But I'm sure there's something that actually exists to do 32:56 it, because it, it would be pretty quick to build. 32:59 If it doesn't exist, you should build it and monetize it. 33:01 [LAUGH] Yeah? 33:04 >> How do you deal with change management of your own internal 33:04 API's at the point of which external clients become reliant on them? 33:07 Particularly if they're not a core part of your business. 33:13 >> Yeah. 33:18 Ooh. 33:18 That. 33:18 I mean. 33:19 I have always liked the model of just letting 33:20 V1 run for as long as you can support it. 33:24 And if you're gonna sunset it, try to give somebody tons and 33:28 tons of notice that this is changing, and here's how you can adapt. 33:31 If you're removing a feature altogether, you know, I think Twitter let 33:34 their version 1 API run for years before they finally shut it down. 33:38 I think it just recently started failing altogether, but I 33:43 mean if it's not something that's core, if it's not adding value to your business, I 33:48 think just transparency and giving enough time to ad, adopt whatever the new 33:53 services or to you know, make other plans if something is going away. 33:57 I think that kind of becomes the 34:01 best of a bad situation really if you're removing something. 34:05 We, okay, were good. 34:08 Anybody else have any questions? 34:10 Cool. 34:13 All right thank you guys so much enjoy you're longer break. 34:13 [SOUND] 34:16
You need to sign up for Treehouse in order to download course files.Sign up