 Hi, everybody. I'm Aramis. I'm going to be talking today about the power of OpenAPI, the new OpenAPI tooling project area. So before we start, a little bit about me. My first PR to the project was a year and a half ago in 2022. I panicked, closed it, and reopened an adjusted PR about three days later. I've been the maintainer for the OpenAPI tooling space for the last nine months, I think, and working in here for about a year and three months. And I also work at DoorDash currently. So what does OpenAPI tooling mean? When I say OpenAPI tooling, what does it actually refer to? So talk about OpenAPI. OpenAPI is a language agnostic schema for defining API communication. So server to server, server to client. And a tooling is infrastructure around a specific concept to improve the developer experience or the user experience when using that concept. So putting that together, we have OpenAPI tooling, which is the infrastructure around writing OpenAPI specs and improving the plugin developer experience for your backstage developers. So what does that actually, you know, in practice mean? So specifically, we're looking at typing your API, testing your API, and calling your API. There might be a theme here. And so, yeah, what is the experience like today? So you might be using Zod. If you're lucky, you're going to be using Express typed responses. You might have a handwritten client, and you might also have shared types between server and client. A lot of areas for improvement. So how can we actually improve that? Step one is write an OpenAPI spec, and step two is profit. So we have automatic request validation, request and response types, auto-generated client, and API fuzzing and testing. We can do a quick demo of what that actually looks like in practice. So here I've done a very simple say hello endpoint for the existing catalog API. It takes in a name and a from of which the name is required and the from is optional. And it returns a sort of JSON message with just a message property. And so I can actually run the command to generate the files here with this. Zoom in a little bit. So what we're doing here basically is running generate and we're passing in a server flag as well as a client package flag. If I press enter here, it'll generate the code to actually hook into your OpenAPI spec that you've written for this case, the catalog backend, but this will be for any plugin backend. Yeah, so this is the server generated code. This is very similar to the YAML. It's mostly just copy-pasted and transformed to JSON. And we're using this generally for the typing experience. So I'll show in a second here, but the idea here is we actually want to give you a type express router that has specific to endpoints, the input output data, as well as validation on top of that. And we also get a client that's auto-generated, which has a say hello endpoint. It takes in the request body and returns this type response. I can click into each of these types. We can see there's that message here as well as the say hello request, which has the name and from. And we can see this whole request, the client request actually uses the discovery API under the surface and sends all of the fetch requests that we would expect. So moving on to the actual, the router experience, I've pre-written this. I can go through and actually show the type of experience as I do this though. So as I'm typing, I get IntelliSense hints for what endpoints currently exist in the catalog. And this is per HTTP method. So I click in the say hello. I also get IntelliSense for body parameters, query parameters, headers, things like that. In this case, I'm going to use the name here and then the from down below. As I said before, from is optional. So this from is required and we want to give the default of backstage. And then hello service dot say hello will return that message body that we expect. So if I were to save this and then run a couple of requests, we can see message hello backstage gone from open API tooling, as well as the optional hello backstage gone from backstage, as well as the request validation I was talking about earlier. So if there's no body, like the name is missing, we'll automatically catch that here. No Zod schema required. It's pretty nice. And then the other piece here is the testing tie-in. So what we're doing under the surface is some proxying to basically validate your unit tests against your open API spec, keep the two of them in sync. So I have two tests here. One of them is a pretty simple just make sure the service value matches the service output. And the other one is what I would say is like a sort of lazily written test. So I have a message one as any. You might see this for like object types or more complex types that doesn't necessarily match the output value, but it's something that gets the types to fix. And the test passes in jest. So if I go ahead and run this, we'll see that the tests actually run through and pass, which is what we'd expect for the jest side. However, we want to make sure that the API is actually being tracked as well. So there's a separate command for that, which is the open API test command. So repo schema open API test, and then the plugin name. This will run that proxy I was talking about. So it checks your unit tests against the proxy to make sure that the values that you're sending actually match your spec. So you can see here there's an error message. Message does not match type string. Received one, which is the value we were expecting here. All right. Back to the slides. So quick shout out to the actual tools we're using under the surface here. So Optic is the one doing the proxying. There's also a really cool feature that they have around breaking changes. So there's a PR currently out for that. That would give you a summary on PRs of the actual changes that happened and any breaking changes for your API that might have happened there. So in this case, there was a breaking change for making a request property required. Back to slides. Okay. So the other company and tool that we're using is called schema thesis. This uses API fuzzing to use your open API spec and actually give you some fuzzing tests on top of that to give you full coverage of your API. No demo for that, but there's a PR out for that currently. So it's in progress. So I'm sold. How do I get started? So the first, this is a QR code for the tutorial on how to add your plugins and integrate your plugins with the current open API tooling, as well as a second QR code for the meta issue for the whole project area. Thank you. We have time for a couple of questions. Any questions for Hermes? All right. Oh, here's one. Sorry. Come in your way. Question one, scared my mind. After seeing this open API and basically what I love about is how automatically grabs all the, all the APIs themselves and shows them in the code. How much easier with it is actually to build upon the custom actions. Like I'm providing some kind of schema and after seeing you running some command and already generated some certain class. So is it really then becomes even easier to accompany some custom actions that use various API calls? Not currently. So the basic use case that I'm targeting right now is really that client to server function. You could write those each as like wrapper client. So the current like the catalog client, for example, is a wrapper client on top of the generated client to give you more flexibility on like input appetites as well as like additional calls and things like that.