ºÝºÝߣ

Editor's Notes

• #2: Hi, I¡¯m Marsh. I work at Apigee.Apigee exists in order to help machines talk to each other¡­¡­ and to help people help the machines.
• #3: Pause for a moment and think about what¡¯s coming in five years.First, a quick reminder about where we are right ²Ô´Ç·É¡­Computers that fit in your pocketComputers that know where they are.Computers that are vastly simpler to use than ever before.
• #4: Revolutions don't happen all that often, and we're deep in the middle of one that started roughly five years ago. On the client side, the iPhone is the poster child. There was no stylus, no mouse. You touched it. It made computing fun again.
• #5: And at the same time, almost as much innovation has been happening on the server side as the client side.IaaS has been driving down the cost of operating datacentersPaaS has been reducing the maintenance burden of the backend stackSaaS¡ªon top of virtualized hardware and operating systems, applications moved into the cloud.And all the clients that proliferated talked to those services using APIs.
• #6: We¡¯re starting to see specialization of those layers, such as Backend-as-a-Service.These exist because time and again the same patterns appear in apps, such as users, activity streams, relationships, schema-less datastores, etc.
• #7: Now back to that question from earlier.Think for a moment how much has happened in the last five years, and then think about what we know is coming in the next 5 years¡­ ¡­?and that amount of change can be scary. Because here¡¯s one thing that was predicted that will happen in 2018. And here¡¯s a hint¡ªit involves machines that are talking to each other¡­
• #8: ¡­ because five years from now, in 2018 we will see SkyNet rise up. And how will the machines communicate? That¡¯s right. APIs. SkyNet IS APIs.So you need to be thoughtful about APIs¡ªyou can¡¯t expect some Schwarzenegger-type to travel through time to save you.
• #9: In the spirit of survival, here are four tips. (story about father-in-law¡¯s foot and what foot-health says about general health)
• #10: Do they have a reasonable business model? Do you understand how they make money, at least in theory? What would happen if they were acquired?(simplegeo example. I don¡¯t know if they were acquired for talent, technology, or what, but what I do know is that they shut down all their endpoints and apps that were using them had to change their code or they stopped working.)Before using an API, look at the company or organization putting it out. Do YOU understand THEIR business model? Judge a service's general health by whether their business model makes sense to you.
• #11: Where are they in their lifecycle? Over the last year, we¡¯ve watched Twitter exert more control over their ecosystem. In the beginning, there were no 1st party Twitter clients. And over time, as mobile became more important, they sent a message that they considered that part of the core Twitter experience. And that wasn¡¯t always good for the folks who had sunk a lot of work into making full-featured Twitter clients.
• #12: Read the Terms of Service¡ªdon¡¯t ignore them. Would you use code in your app that wasn't licensed? It is just as irresponsible to not understand how a service's ToS impact your app.Aviary¡¯s are the easiest to read. If they spent that much time considering the needs of their developers on just the ToS, imagine how thoughtful they are about the API itself!
• #13: 4. Remember, you are sharecropping. This is the price of being able to build amazing apps without having to build all of that technical complexity yourself. But it means that there are things that are beyond your control. The ground you¡¯re working doesn¡¯t belong to you. And that¡¯s not a bad thing, necessarily, it just means you need to be thoughtful about how you build.(ask who lives in SF, then who rents. Those with hands up have chosen to make a home in a building that isn¡¯t theirs. Remember when you use an API, it's like building a home in a house that you don't own.)(Farm Security Administration sharecropper photo of Mrs. Handley and some of her children in Walker County, Alabama.)
• #14: ¡­ because this is what happens when you build something without expecting the ground to move. Thinking about how to be flexible when the ground shifts is important to making great apps
• #15: ¡­ and it is why AT&T Park, where the Giant¡¯s play, has these rubber sections in their pipes so that the sections of the stadium can move somewhat. You can do the same thing with how you build apps, so that when things happen beyond your control, everything doesn¡¯t break.
• #16: Those tips may help guide you¡­
• #17: ¡­ but there will be plenty of other issues you¡¯ll face. Let¡¯s talk about the ways things used to be built, and the ways in which we¡¯ve seen application development shifting to what we¡¯re calling, ¡°The NEW 3-tier architecture.
• #18: As a web pattern, we used to see this a lot. The browser was the presentation layer, and it used HTML, JavaScript, and CSS that would be rendered in the browser.
• #19: There was logic that ran server-side¡­
• #20: And servers were hooked into databases.
• #21: If you put it together, it looks like this.And this 3-tier web architecture did a pretty decent job of powering the web and the mobile web.But when you move to mobile apps, and when you start leveraging APIs , you get¡­
• #22: The NEW 3-Tier Architecture. Now we see a presentation layer similar to before, but the data is all passing via APIs. The proxy handles the technical logic, and the backend handles business logic.
• #29: Transformations, pagination, authentication¡­
• #30: And enjoy life in rainbow-land.
• #31: We write and blog about these kinds of topics all the time. You can find a much longer versions of the 3-tier architecture and lots more about apps and APIs.
• #32: Special thanks to @landlessness and @kevinswiber for some slides, ideas, and general awesomeness.