 So, directly four floors above my office in Kaltura Tel Aviv sits a developer named Omri. He has one of those obnoxiously loud red backlit keyboards, you know those, and when I came in to interview him for my talk, I actually challenged him to a typing speed test. Now I won, and it's probably only because his first language is Hebrew, because he's very fast, and he asked me if I came upstairs to throw him under the bus in my first lines of my talk. He's actually a very interesting developer. He doesn't like coffee, which I found out in our recent hackathon. Lately he's been listening to the OK Computer album by Radiohead and playing Red Dead Redemption 2. Omri is my JavaScript guru, so it's probably his favorite language. I'm not very good at JavaScript, but at Kaltura he's actually a PHP developer working on our media space or private YouTube if you may. Now why am I telling you all this? Why do you care about Omri? Because client libraries, that's why. In order to work on our media space, Omri actually uses the PHP client library that we built specifically for media space. He says that he can't imagine life without it. So I said, okay, what would you do if you didn't have the client library? And he said, probably build my own mini library that would have all the API calls that I use on a daily basis. I said, great, that sounds really cool. What happens when we change the API, which we do very often, and your library breaks? And he says, well, this is just a hypothetical situation, right? Don't take away my library. But I guess every time we change the API and my library broke, I would fix it accordingly. Now how many of you are familiar with this kind of annoying situation chasing your tail to fix something that constantly breaks? Yeah. Thank you. So I'm glad you came. Now on a totally separate note. How many of you are familiar with this line? You seen this? If you go to a lot of developer conferences, which I do, you see this a lot. Now I used to think it's condescending. Do you think it's condescending? Kind of. Well, I'm a developer evangelist, and I've been working on our developer portal for about a year. And I've come to see this a little bit differently. I think that in this context, people just means those who deserve to have life made easier for them, right? And developers in this context, or in every context, means those who are supposedly smarter than the rest of the world and can handle the hard things better than most. Put this all together, and you and me and developers, we're all just regular, fascinating people who have favorite afternoon snacks and opinions about coffee and keyboards and operating systems and programming languages and all of the methodologies and tools that come with those programming languages. And where am I going with this again? Client libraries. My name is Avital Tsobelli, and today I'm here to speak to you about automating client library generation. Not for the fact itself, although it is a pretty cool thing, but as a powerful tool for making the lives of developers exponentially easier. And I'm talking internal developers, external developers. I'm talking those building the API and those using the API. I'll tell you about how Kaltura ended up with over 35 client libraries with our homemade solution and how you can do so yourself with a generic solution that's super easy to implement because we all have better things to worry about than fixing client libraries that are constantly breaking, right? So let's back up a little. It's 2007. I'm in high school. Kaltura is an open source video platform. We have the player, the widgets for uploading videos to the KMC, and the KMC, which is the UI. All of these are talking to the API with the Flex library. Now we knew a few things at the time. We knew that all of the Kaltura products are going to be built on our API. We knew that the API would get really big, there would be lots of objects being thrown around, 758 to be exact, but who's counting. And that string requests would become a pain in the butt. We also knew that if you write a client library to access the API and change the API and break the library, 40% of your developers are spending their time fixing that library. Sounds time consuming, right? So what did we do? We wrote an XML schema that completely describes the API, complete with objects, classes, services. And then an XML generator that automatically creates that XML from the API. Lastly, for every language or function that we wanted a library, we just wrote a generator that would parse that XML and create that library. Basically code that writes code. Who doesn't love that? What this meant was that it was super easy then in 2008 to write a batch client library that handles all of the hard stuff, all of the slow stuff that happens behind the scenes, transcoding ingestion. And then a PHP4 library, obviously, because the API is written in PHP. Then we were able to write a testing library super easily that makes calls against the API and the community started asking for access so we gave them PHP5 because it was easy and we could. We didn't anticipate they would. And then in 2012, we wrote smaller Zen libraries for all of our smaller applications, community asked for more access so we were able to give them Python, Ruby, Java, and C sharp. 2017 was a really big year at Kaltura for client libraries. We wrote an Ajax library to replace our awful JS library, came the time for async, so we wrote all new node, Java, and mobile libraries with multi-threading support. And then this past year, we rewrote our KMC, our Kaltura Management Console, which was awful. We decided to do it in Angular, and why not also create a TypeScript library along the way. Now, making this sound super easy because relatively it was. Why is that? Automation, 2019, and we're able to have 11 client-facing libraries and over 20 libraries that you use internally. And thanks to automation, we only need to write the library that we need once. And with the updated XML in place, that generated library is always using the latest version of the API. Now, in my previous life as a back-end developer, I actually spent a year implementing over 75 APIs to our platform. And what I can tell you is that when an API breaks or whenever you're doing breaks and the API has been updated six months ago, that's the bane of everyone's existence. So I'm really excited about this. So if you look at this diagram, this Kaltura logo here, that's our server logic or the API. After that is where the introspection happens, where the XML is created. Then we generate the client libraries, CI puts them in GitHub where they're tested, and all the passing libraries get put in the public repo, as well as package managers for Ruby Java, Python, and PHP. And the most important and very simple part is that a script runs every night that generates the XML from the API and the client libraries from the XML, which means that internal and external developers are always getting the latest and greatest version of the API in no click whatsoever. So the other most important part is that this is an open source library, hosted by Kaltura, that you can use to generate your own XML, to parse your own XML, write your own XML, and create your own client libraries. Now, if you click on that link, these links will all be available later, I guess, if you click on that link, this is what our XML looks like. Not doing a demo because I have 15 minutes. As you can see, it contains the enums, the classes, with all the information and the properties that they include, the plugins, the errors. Now, in that same file at the Knowledge Center, you can also download the project files for creating your client libraries. What you end up with is three files that look like this. They're all in PHP. Sorry about that. You can't see that. But the first class is an abstract class that is extended by the meat of your project, which you'll get to, and that provides base helper functions for generating. Next is a script that tests the library creation. This class is what saves the files to disk. And then thirdly, the meat of your generator. This is the class that parses your XML or your spec or your schema, whatever it is, and actually creates the file contents. And this is what our client generator repo looks like. Here, you can find all of the client generators that we have if you're curious what that looks like. Python's my favorite language. This is what it looks like to generate from the API and create these file contexts that actually create your library. But that means that our external developers can just go ahead and download that file and do file handling, which is one of the most annoying things in the language that they like. I'm actually working on a Go project myself because we've had some demand for Go, and we don't have a Go client library. And I'm about to embark on that mission and see where it takes me. The guy who's been writing this develop the client libraries since 2007 says it takes him about a week, two a month to write each library. So you can check in with me in three months and see how I'm doing. Thing is, you're probably thinking, well, yeah, I'd love to have 15 client libraries in various languages, but I don't have two months to write each one. Well, here's the good news. As excited I was to show you this open source project, the good news is that plenty of out-of-the-box solutions exist to help you spec out your API, one being Swagger, which you've probably heard of, tons of open source tools that take your API, whether it calls all of your API on points, for example, and creates this open API spec, which is the standard for describing an API. You end up with something that looks like this in JSON or this in YAML. How many of you are working actively on an API that's already got a spec? Okay, so do that. And once you have a spec or a schema, whatever version you choose, the next step is this, you can either generate your client libraries alone, you've already made half the process easier, or same thing, Swagger and other tools have plenty of open source tools that will help you generate client libraries, among other things, from those schemas, and what you end up with is a client library that is always accurate, up to date, and properly versioned. The thing is, auto-generated code is not always the best experience for Kaltura. I mean, Swagger didn't exist at the time, this was 10 years ago, but it wouldn't have been the greatest solution either because so many of operations need so many steps with the API in order to work, and so we did it by hand. But for smaller operations, it's actually a pretty good solution, and the truth is that API as a product is becoming more and more popular, and so these tools are becoming more powerful. And the truth is that we actually, at Kaltura, use Swagger for part of our process, do you remember this diagram? Well, we actually use something called Lucybot to create our entire documentation portal. So the main developer at Lucybot actually wrote us this handy little tool which converts our XML to an open API spec, and then we're able to use Lucybot, which is a project that takes that entire schema and puts the contents into a pretty HTML page to create your developer portal, complete with a console, workflows, interactive documentation, which I'll show you. So this is our API portal to my baby. Go to the console, I mean, you've seen developer portals before. So with Lucybot, we're able to show you all of the externally facing API endpoints, let you play around with them, choose any parameters, and of course, change languages based on the client libraries that we have, which is really fun. Because who doesn't like copy pasting code? The more powerful thing though is our workflows, because in Kaltura, a lot of our operations require many steps, like I mentioned. So for example, with video ingestion, first you need to download or create an upload token then actually upload the file, then create a media entry with all of that file data, then connect the upload token with that media entry, and lastly, see what your video looks like in our Kaltura player. And the thing is that it's super easy to create these workflows. All you need to do is click on this button and then select which API endpoints you want in your workflow, which parameters you want for those API endpoints, and which values to carry over to the next step. I actually get so excited when I talk about this because I think it's so easy and so awesome how powerful it is. And the thing is that we all just want to quickly and easily move our task to the done column. So being able to do things like this and being able to refer back to workflows and being able to copy paste code, that's awesome because developers who aren't writing the API don't need to know about the intricacies of your API. And so if there's one thing you take away from this talk, one thing, define your API. Create that spec. If you're about to create an API, consider doing it spec first. If you already have an API, see what the best way to now look back, take some time and define that because you'll be able to do so much with that spec, with that definition. And you'll be able to use it for so many different things. For example, it'll now be the source of truth between you, between your internal developers. You'll be able to look at it and spot design patterns, spot possible flaws. This is always now, this is what your API looks like. You'll be able to create those internal libraries that include all of the requirements that you might need for one application but not for another. And developers working internally have a much easier time. You can join API marketplaces or other places where developers can be exposed to your API and play around with it so that you can get people to start using it. And lastly, because client libraries are your relationship with your external developers. Give them the languages they love. Give them real code snippets they can copy. Give them a sandbox they can play around with. Let them fall in love with your platform while they're still in their developer portal. Have an API spec, automate everything so we can all go home and listen to our favorite music albums. Thank you. We have 37 seconds for questions. Any questions? So one of your motivations that you mentioned for doing this was if the API breaks, if the API changes. If that happens, doesn't the API client change and therefore the code that is used in the client library? I mean, we know if the API is changing so we're not gonna release client. I mean, we know if the API is broken, we're not gonna release client libraries. API changes are good. Broken API is not good. Breaking changes are not good. So was your question about broken API or changing API? We get to decide obviously when we're putting out client libraries and with which version of the API but the idea is they're always using the latest version.