 API for longevity talk. If you're not here for that talk, you're in the wrong place. Quick disclaimer, I'll work tech. This is not a talk about how to code your API. If you're like, hey, look, I wanna know how to use a framework, I'll learn how to code it. There's great tools out there. Rails API is a great framework. Grape's out there. We're actually talking about things that you need to know to build a successful API long term. So a little about me. First and foremost, I'm an API fanatic. Otherwise, I wouldn't be doing this talk. I'm doing this talk because I've had problems with APIs. How many people here have used an API? How many people have used just hypothetically a giant social media network API that breaks every two months? Just hypothetically. Is that fun or is that annoying? You still, yes. Are you with Facebook? Okay, as I get fired. The other thing I wanna point out is that I'm in dev relations with MuleSoft. I wanna thank MuleSoft because they're the reason I'm able to be here. And that's the other reason for this talk. MuleSoft deals with enterprises. We serve about 30% of the global 500. So a company that you're all very familiar with. And so we talked about these best practices and these issues. These aren't just things that I'm saying, hey, look, these are things you can do to make your API last longer. These are actually things that even the largest companies forget to do. This is the same advice that we give the Fortune 500s, the global 500s that we're gonna give you guys today. I think we already know this. APIs are changing the world, right? I mean, today there are over 13,000 public APIs. 13,000 of them. And the best part is that doesn't include all the mobile APIs. That doesn't include all the enterprise APIs. That doesn't include network to network APIs. That's just public APIs. There are hundreds of thousands of APIs out there. And these APIs are powering and connecting tons of different things. They're connecting phones, watches, glasses, cars, refrigerators, thermostats, in-home robots, and more. Why don't you guys think about that? Everything is becoming connected by APIs. Your home security system connected by APIs. Soon you're gonna go home and it's not gonna be, oh, you arrived, your house is gonna say, oh, he's leaving work. There's traffic over here. We'll know all these different things. Just think how this can all work together. But in order for the internet of things to work, APIs need to remain persistent because you don't want a security system that says, hey, somebody broke into your house, I need an update. Sorry. The other thing that we forget about APIs is versioning and making changes is very, very expensive for everyone. It's not just expensive for the company to version their API and have two different versions that they have to support. It's expensive for the developers who have to migrate to that new version. Thankfully today, we're gonna talk about five very simple steps, five simple concepts that you can use to build an API that lasts. They are, go with a long-term mindset. That seems kind of like a no-brainer, like duh. But if you don't think long-term when you start, if you think I'll just version it when we need to make changes, you're not gonna be successful. You also need to understand what you're building. Another duh, but most companies do not take the time to understand what they're building or why they're building it. You don't like something called spec-driven development, which we're gonna talk about, and then following best practices and repeating those steps again and again and again. Think about the long-term. Think of your API as a contract. Forget about versioning for a second. Put versioning outside of your mind. This is my favorite slide, by the way. How many people here are designers? Okay, he's looking at you like, oh, I don't even wanna talk to this guy anymore with that. You're not that good at design. And if people are gonna be like, no, I don't believe that, I'm gonna prove it to you. You can pay a little bit now in advance, or you'll pay a lot more later, and you need to think things through. The mindset is everything. Here's the thing with your API. Your API is a contract. When you use the social media API and it breaks, what's your first thought? I'm gonna call them, give them a gift basket, thank you. I like to do it, they just dude, why they do that. Now imagine if that API was critical to your business's success, because a lot of APIs are. And when you break backwards compatibility, when you break that contract, you're, in essence, telling the developer, here's something you can use, but it might not always work. My words, eh, okay. And not only are you costing them the time to build that application, you're providing them from focusing on features. So we need to step back and say, no, it isn't okay to break backwards compatibility unless we absolutely have to. That means you have to think through every aspect of your API. You can't just build it, you have to think it through. Think about, who is your API for? What type of API are you building? Are you going to maintain your API? How so? How are you going to document it? How are users going to interact with it? How are you going to manage things like authentication, provisioning, and throttling, protecting the developers credentials? What about attacks against your server? And then how are you going to manage support? Now we're not going to go over the last three or so here today in depth, but this is one of the most important things you can do. When you build an API, you want to find a management tool for it, a proxy for it. Whether you build your own and put it in the cloud, or whether you go with another service. And here's the thing, I'm with MuleSoft. MuleSoft is an API management provider. This is where I get fired. I don't care if you use MuleSoft, if you use Mashery, ThreeScale, Layer 7, IBM, and I don't care. You should probably look at a solution, find a solution that meets your needs, and have that layer of protection. And then think about how you're going to manage support. But as you build your API, who are your end users? We forget this. We say who are we actually building for? We're building it for current customers, for business partners, for third party services. One of the things I love is we say, hey, we're going to build this API, and we forget to talk to the clients. So I had the privilege of contracting with a company, and we spent six months building this amazing, amazing API. Now I was running PHP, so please don't judge, but it was okay. And we launched this API out in the public. And I know the code was perfect because I wrote it. I don't know why people are laughing at that. And three weeks later, we realized we had a problem. No one was using our API because it didn't meet their needs. We spent three months on top of that trying to fix it. You know what we did with that API? We scrapped it. Gone. All because we understand who we are doing the API for and what they want to do with it. List out why you're making the API. We get all these big companies that come to say, we want to build an API. That's awesome. What do you want to do it for? We want to expose our data to our users. Okay, that's a good start. But then what? You'd be surprised how many companies can't answer that question. We're like, what do you mean? What do you want them to do with that data? What do you want them to do with your services? How will they interact with your API's existing services, your other services, and services they would use with integration with your API? Do they still have the actual actions that they want to do or that you want them to do? And here's my two major lines for all the developers out here. First off, do only what is necessary. When you build an API, especially when you build that first version, you're building the foundation. And you can get really, really fancy and your house is gonna crumble. Do only what is necessary. Don't get fancy. Don't reinvent the wheel. Don't try to get creative. Don't try to create your own spec. Don't do it. You're gonna work. Instead, list out what they need to do. At this stage, we're not thinking about crud. We're not thinking about how the API's gonna work together. We're simply saying, hey, we have users. They wanna create a user. They wanna message a user. And then you notice a message and we say, hey look, they wanna send a message to a user. It's okay to put in two different places. Why? Because as you evaluate your API, you can say, okay, these need to work together, and this should probably go in the messages resource, but maybe we want to put a hypertext link in the user's resource for that. So we'll list out all the things that they can do with it or that you want to be able to do so you're thinking the whole process through. And then are you building a REST API? Are you building a partial REST API? Soap? RPC? Which one of these should you build? Anybody? Okay, here REST. I'm inclined to agree with you, but the answer is it depends on what your customers need. If you're working with large legacy companies that are like, hey look, we have all these Soap libraries and that's what they're using, that's what they're counter with, it may make sense to build a Soap API. Yes, I feel dirty saying that. But why are you building that API in that format? What's it gonna mean for your development? What's it gonna mean for usability? What's it gonna mean for longevity? And you shouldn't just say we're gonna build REST because everybody's using REST. You should know what the advantages are compared to Soap, REST, RPC. You'll notice that with Soap and RPC, they're very tightly coupled. Know the different issues with it. Also, don't just say we're gonna do REST without understanding the constraints of REST. Do you understand what REST means? Do you understand what it means to do client server to have a stateless environment, to have a casual or layered system? So do your research first. Because here's the secret, most APIs are not RESTful. Most APIs are RPC or partial REST. Dr. Roy Fielding said, hey, let's not play semantics. If your API does not include hypermedia, it's not RESTful, it's not REST. And given the fact that he created the dissertation about REST, I think we go with that. And this is why it's important to understand what you're doing with your API. Because if you don't understand, you're gonna deviate from that status or that plan. One company was saying, going, hey, we got this API, we wanna build this out. Let's use JSON here and HTML here. Let's do a query string, a post here, and then do a JSON, a post here. You want no secret, it really didn't work out well. And that also means thinking beyond today. That's another mistake we make, is we say, okay, we're gonna build an API for today's roadmap. This is what our product's gonna do, this is what the API needs to do. You have to think beyond that. You have to think two, three years down the road. You have to think, what can the API do when you have new features that you've never even thought about? Or is my favorite close from Al Gore? You have to expect the unexpected. Now I'm gonna go back to that design phrase where I said you guys aren't that great at design. And I'm gonna probably get kicked off here. Dr. Ray Filion puts it very succinctly. He says, hey, we're really good at short-term design. We're usually pretty bad at long-term design. How many people here have written code? Just a few people, okay. How many people have looked at that code a year later? How many people have said, that is the best code I wrote ever? How many people have started building an application and then three months later you're like, I'm boxed in, I can't go any further. I put myself in a corner. Because we're really, really good at short-term design. The problem is that if we think about the now and we don't evaluate for the long-term, we're gonna get issues. And that's why we have to think long-term right off the bat. That's why we have to plan not just for the day but for the future. And that's why we have to be very, very careful about everything we do. Which brings us to versioning. One of my favorite things with versioning is we say, oh, if we need to make a change, we'll just version the API. Versioning is a necessary evil. It's not something you want to do. Versioning creates several different problems. First of all, there's backwards incompatibilities. Multiple services they maintain creates confusion among developers. Before, Mule Software worked at constant contact as their developer evangelist. And right as I started, we launched V2 over API. By the way, my shameless plug for constant contact, you should check out your API. The problem was that now we had two different systems we had to support. We had two different systems we had to maintain. Two different systems we had to do patches for. I got a call one day from a developer saying, hey, I have a problem with your API. Like, oh, no problem. Which version are you using? Your version? Oh, well, so how does it work? Oh, well, I make a post request and I get data back. And I kid you, I was like, okay, Jason X and I was like, I don't know. I just make a post request. We spent 30 minutes trying to figure out what version of the API he was using and then developer adoption is nearly impossible. You're gonna be maintaining both APIs for a very, very long time. You should version. And you should plan to version your API when you have backwards incompatible platform changes. In other words, you change your platform completely. The UI changes, the surface changes. Everything's different and no longer functions the same way. Then it's time to version your API. Your API is no longer extendable. Basically what we're trying to avoid. Doesn't work anymore. Or your spec is out today and you're using soap and your customers want rest. But you should not version your API if you're just adding new endpoints or you're just adding new data or you're changing technologies. Apparently going to Terubi, which is a new format of Ruby that I'm working on. You should not do it because you change your application services. Your API should be decoupled from your service layer and also from your technologies. If you're using Twilio to send SMS messages and you switch SMS providers, that should not affect your API. If you change your programming language, it should not affect your API. It should be separate. And versioning does not excuse poor design. And here's the thing. With that API that we spent six months on, we spent six months building that API, three weeks trying to figure it out and another three months where we finally basically spent 10 months on this thing to throw it away. Wasted hundreds of thousands of dollars. You can either do the work up front or you will pay for it long-term. There are no shortcuts. There are no quick fixes. But there are things we can do. One of the things we can do is something called spec-driven development. And with spec-driven development, we actually define the API before we write a single line of code. We can use design patterns to ensure that it is standardized, normalized and uniform across the entire form of the API. We can actually mock the API, send it to users, get feedback from the users and find out what doesn't make sense. The Facebook API has an old graphing consistency. And the problem is they didn't catch it. They didn't know about it. And now if you do one type of search, it works this way. If you search Odea a different way, it doesn't work. And so they're like, hey, this is a problem, but it's too late. It's in production. People have found the workaround. We can't change it. It allows you to make necessary changes, again, without having to write services, without having to write code. And one of the big things with spec-driven development is you write code to the spec. You don't write the spec to the code and you don't deviate from the spec. And here's where I get killed by people. Spec-driven development means taking the best of two worlds. You take a hybrid between agile methodologies and then when it comes to the spec, once you have done the agile cycle, a waterfall methodology. Basically saying, this is the spec, now it's not changeable. This is our documentation. We're building to the documentation. Of course, so I don't get killed on stage. I'm a big fan of agile, love agile. And I would encourage you to use agile for the development, but once you have your spec, it should not be changing. In essence, you wanna do a two-cycle approach. You wanna do the design phase, and then once you design it, you wanna move one direction, one way with development. Just kind of a larger look at the agile design cycle. The first thing you do is you define your spec and then you prototype it. You mock it, let people get feedback and tell you what they like, what they don't like, what makes sense, what doesn't make sense. Let them make calls against as if it was real. Get user feedback because then you can say, this works, this doesn't work. And if your spec is perfect, go on to development. If it's not, make some changes in your spec, prototype it, get user feedback, and you just continue that cycle until you have the perfect spec, the perfect blueprint. And people say, but that adds a week to two weeks on the whole cycle, it does. But that's gonna save you that three weeks of, oh, this doesn't work, and that three months of, oh, we can't save it. It's gonna save you a lot of time, a lot of energy, and a lot of money in the long run. The goal here is about using agile user testing and carefully designing and prototyping your API. You're gonna find 99% of the issues with it. Most APIs do not fail because of the code's bad. Most APIs do not fail because the endpoint doesn't make sense. They fail because there's inconsistencies that eventually box them in where they cannot expand it any further. Another thing to think of, how many people here have done work for clients? Let's say you're working on a photography website, they say, look, I want a black website with these pictures, you build that. It's absolutely perfect, right? No changes. Same thing in API development. Why do we try to say we're gonna do this perfectly without getting user feedback? Of course, the problem has been, it takes a lot of time, a lot of energy, a lot of money to build those services and write that code. The good news is that there are now several new specs out there that allow you to do this and make it very, very easy. There's Raml. Raml is backed by several, several different companies in the industry. There's IODocs, back by Mashry. There's Swagger, which is reverb, Apigee and Threescale. There's API Blueprint, which is apiary. Personally, my favorite, and of course I'm biased with Milsoft, is Raml. And the reason I like Raml is because it allows you to do several things with your API. You can define your API in just a few lines of code. You don't actually have to write Ruby to build your API mock. You can see what it will look like as you go, which means you actually get a visual representation of your API as you build it. So you can look at the responses and say, this response makes sense, this one doesn't. You can quickly prototype it. Here's the great thing about prototyping it. You can send the code or the URL to developers around the world and they can make calls against if this was a real API. You can quickly make tweaks and changes. You can use it to document, use it to interact with your developers. You can even build SDKs. But what I really like about Raml that makes it unique is you can do design, patterns and code reuse. And this is very, very important when building out your API and building your spec because if you use design patterns, if you use code reuse, it means that you're gonna have a normalized resource style. If all your collections work similarly and all your items work similarly, then you know that there's not gonna be a large deviation from them. They're nice about Raml and actually all these specs is they have visual designers. This is what Raml looks like. Very, very simple to use. But remember, your spec is not a one and done thing. It's a blueprint for your API. Just like you're gonna add a new addition to the house, you don't just say, okay, I'm gonna tear this part of the house down, put a window there, put a window there. You plan it out, you say, this is what I'm going to do. The same thing with your spec. You should never have code that changes a resource or changes a method that's not defined in your spec. Your spec should be your blueprint to say, this is what you want things to do. And then the next thing you wanna do is incorporate best practices. This is going to ensure that your API meets your needs. What you wanna do, you wanna use nouns. With REST APIs, you wanna keep them as loosely coupled as possible. With any API, you wanna avoid tight coupling. By using nouns and saying users, you can create multiple methods on the user versus having tightly coupled. I wanna create a user. I wanna get a user. I wanna delete a user. The other problem with this is you can run into ambiguous terms. You can run into things that are very similar. For example, I saw one API where it's delete user. Delete user by ID. What's the difference? And they had fantastic documentation. Utilize crud. This is actually my favorite thing because I'm from Minnesota originally and we always go, oh crud. And nobody gets it. Crud stands for create, read, update and delete. There are five main methods you wanna use. The first for create, you wanna do a post. For read, you wanna do a get. For update, you wanna do a put or a patch. Now, put and patch are very specific. Put is a complete overwrite. If I do a put and I don't put a first name in there, the first name gets overwritten and is now blank. Put says update the record exactly as I give it to you. All of it. Patch on the other hand says I wanna patch that record. Therefore, if I give you a last name and I give you nothing else, the only thing affected is the last name. Nothing else gets modified. It's very, very important that you take the time to understand crud because users and developers are gonna rely on this to interact with your API. And then delete is super complicated. You just use the delete HCP action verb. Now, I'm gonna say the scary word of the day. Use hypermedia, or hadeos. Hadeos stands for hypermedia as the engine of application state, which is a really fancy way of saying that when people use your API, you should be directing them to what they can do next. That it shouldn't be stacked. They shouldn't have to know the URIs to your API. And people like to get in these big arguments about hadeos and make it really complex. A friend of mine, Dr. Keith Casey Jr. likes to describe it as create your own adventure book. If you open the book and you say, I'm gonna go here and this is okay, you went here. You now have two options. You can go here, or you can go here. That's exactly what hadeos or hypermedia is. It's telling what their options are. Another way to think of it is, if you go to yahoo.com and you want to do the news, do you go back to your address bar and say yahoo.com slash news? Or do you click the news link? And then when you wanna read a story, do you type in that URL or do you click that story link? That's what we're doing with hypermedia is we're sending back actions, we're sending back links telling them what they can do next. And what this does is it provides an extensibility and flexibility to your API where if implemented correctly by the client, if something needs to change, maybe you need to add extra validation. So you had a messaging system with the ID and you realized, well, people are just spamming people. This doesn't work. We're gonna add a last name just to make sure they send it to the right person. Prior to hypermedia, that would break backwards compatibility. It would just stop working. They'd have to update their code. With hypermedia, if they used the hypermedia links, it would automatically work for them. They wouldn't have to change anything. Now with hypermedia, don't reinvent the wheel. There are several specs already out there. There's how, which is the hypertext application language. There's JSON, LD, JSON language definition. There's JSON API and Siren and many, many, many more. Each have their strengths and weaknesses. One of the great things about how is it's nestable, which means that if you can respond to the collection, each item can have its own hypertext links. And how complicated is hypertext links? This is what they look like. You notice that we have our data returned. But under our data, we say, hey, here are the links. Here are the options of what you can do. We have edit. This is the link to use if you wanna edit the user. We have message. This is the link if you want to message the user. Again, a very simple flow that says these are your options. The nice thing about hypermedia as well is what if those options change? Cause rest is stateless. What if they can no longer message the user? How do you address that with your API? How would you address that in the hypermedia? You just remove the link. Say it's not there anymore. That's no longer an option. So it gives you a lot more flexibility with your API. If you add new resources, you add new options. All you have to do is add it in the hypermedia, and those are now immediately available to them. And even how they build their API, they can take advantage of that. Now, one of the biggest best practices that gets missed, and I did a presentation API strand, I even forgot to mention it there. You wanna take advantage of header tags. You wanna take advantage of accept and content type headers specifically. The reason for this is because it now creates a very flexible API. Let's say your users are using XML. That's what they're used to. They want XML. And then you have users that says, I want JSON. If you're not using the accept header or the content type headers, you basically say, well, I'm giving you XML tough. But if you use those, you can say, okay, if the content comes in as type JSON, I'm return JSON. If it comes in as XML, I'm return XML. The nice thing about this is if there's a new standard that comes out, if something changes, or you have a customer that has a very specific need for a very specific content type, you are flexible enough where you can adjust to that, where you can adapt to that. So very, very important that you use the content type and the accept headers and respond to them that way. Hypothetically, when you build your API, I should be able to send a content type JSON with an accepts XML. And you should be able to send me XML back, hypothetically. When you build your application, you should not have that hard code layer. You should have an interpretation layer built on top of your application to send back the type or the format that they want. Keep in mind that REST requires a uniform interface. So that'd be a violation of REST. You don't want to do that. You don't want to give them XML if they send JSON. But your architecture should allow you to do that. It should be decoupled enough that you can do that. Also, send back response codes. Make sure you use the right response code. Very commonly, you'll do a post request and you'll get a 200 back. That's not the right response code. 200 okay is not correct for something created. You want to use a 201. So know your response code and use them. If they make a request and maybe there's an error, tell them they did an error, but maybe they make an update and nothing changed. Send them back a 304, nothing changed. Let them know that. Tell them they're not authorized or forbidden. Tell them the page doesn't exist. Tell them they're requesting an unsupported media type. If I do XML and you only support JSON, let me know. Give them very specific error code. And if you're really feeling creative and you're like, look, I want to go the extra mile, you can send it back one of these. Keep in mind, 418, you should only send if you're actually a teapot. 420, some of you will get, some of you won't. Kudos to the ones that don't. In California, that's like, yeah, we know it is. Also use descriptive error messages. One of my biggest, biggest, biggest pet peeves and actually a big downfall to APIs is they're not usable. They don't provide good usability. I went to an API and I made a call and I got back an error message that said, this didn't work. I got another one, and I kid you not, this is a real error message that said, we're sorry, we were building a rocket ship. I'm not gonna lie, I nearly drove from Minnesota at the time down to wherever they were to go visit them and see this rocket ship. I was not happy. Give them as much information as possible. Tell them what's wrong. Give them an actual error response. And go the extra mile. Give them a description, say this is what went wrong. Tell me explicitly, working with one API, no matter what happened, it said, this action's not authorized. I spent 45 minutes to find out that I was missing an ID. Tell me I'm missing an ID, make it easy on me. If you can put a link there, give them the information to fix it because one of the biggest downfalls to APIs is people can't use them. And if developers can't use your API, no matter how well thought it out it is, no matter how much work you put in it, it won't be long-lived. And that goes with documentation as well. Make sure your documentation stays in sync. You would be surprised the number of companies that say, look, our documentation's out of sync. We need to rebuild the API. Can't you just fix your documentation? And this is the other advantage of spec-driven development, by the way. That spec you use to define that blueprint to say this is what we want. That spec you create that let developers go fearlessly building your API because now instead of having three developers going down and saying, okay, you build that endpoint, you build that endpoint, you build that endpoint, and let's hope they're the same, let's hope they work together, you know exactly what I'm building. You know exactly what I'm building. You know exactly what I'm building and we're all building based on the same model. And now we can take that same spec and we can use it for documentation without having to create new documentation, without having to change things using these open-source projects. And then finally, when adding new things to your API, you really, really wanna be sure to go out with a long-term mentality. It keeps going through, the cycle continues. Everything you do, you need to follow those four steps. Even if you're just changing one simple thing, go back and say, okay, let's design this. Let's look at this, let's prototype this, let's get user feedback. One of the hardest things for developers to do is say no. And immediately the reaction is no, it's not. But if you think about it, if I say, hey look, can you just add this? And you're like, oh yeah, it's two lines of code, super easy, I'll get that done in five minutes. The problem is if you make that change without thinking through long-term, you're looking at breaking your API down the road. That change may come back to bite you. So again, everything needs to be very, very carefully analyzed. It only takes one tiny, tiny little thing to mess up your API. It only takes one little thing where you often can no longer extend the API, you can no longer build upon it. And this is the secret to API longevity. There are tons of best practices out there. You know, there are tons of resources out there that I encourage you to look at. But the secret to longevity is not saying, I'm gonna incorporate the best practices. Because you can do all the best practices, but if you don't think it through long-term, it's not gonna work. You can have the best documentation in the world, but if you don't use a spec-driven development, if you don't carefully design your API step-by-step for the long-term, you're still gonna get in that corner where you can't extend it. Because here's the best part about building APIs. Building an API, writing the code is easy, right? I mean, you're literally saying, okay, this is what I want the code to do. Sure, there's a debugging aspect, but you're just writing code. There's frameworks out there. There's Rails API. There's Grape out there that you can use. But designing the API is the hard part, because once you push it in production, you cannot take it back. Once it goes live, you cannot change it. So I would very, very encourage you to be very, very careful in developing your API. Use spec-driven development. I don't care if you use Raml, I don't care if you use Swagger, API Blueprint, look at a spec, grab it. Incorporate the best practices we talked about. Use Hades or Hypermedia. Use CRUD. Understand what REST is. Make sure you're accepting content types. And make sure that you're as flexible as possible. We build our applications that way. When we use an MVC framework, we try to make it as extendable as possible. We have our services layer. We had this layer, like, okay, we have all these things modulized so we can change it if we need to. The difference with MVC versus an API is you can't change it once you've done it and pushed it public. There's a lot more information at blogs.mulesoft.org. We actually have a best practices series that goes far more in depth. Unfortunately, we don't have all the time in the world to go into every little thing. So I encourage you to check that out. If you enjoyed the presentation, I'd really appreciate if you sent a tweet to MuleDev said, hey, thanks for letting me, thank you for letting Mike speak. If you did enjoy the presentation, you feel like holy crap, this guy just wasted 45 minutes of my life that I'll never get back. Come see me, I give out bribes. Okay, thank you for laughing at that. The one guy's like, ah, you're just, last but not least, this is my shameless plug, one of the things that we're trying to do with Mulesoft because we work with these enterprise companies that struggle with these issues. We work with these companies that, even though some of this may seem like common sense, they don't follow these practices and that's why they're so important. We're launching a kind of a beta program where you can earn points, earn rewards, get different things for learning more about best practices and APIs. We're in a private beta. I'd invite you guys to join that if you'd like to. With that, I think I have a few minutes for questions. This is high time. You know, it's gonna be hard. It's gonna be hard. It's gonna be hard. It's gonna be harder. I'm not quite sure about knowing about that. I'm wondering what you're gonna ask me to do with my future, what you expect me to do with Mulesoft? Why don't you comment down below what you think might be the best? I'm gonna ask you.