 Bonjour and good morning. My name is Victor. I'm from a company called the Cosmonic and I'm here to talk to you about extending backstage with plugins built with WebAssembly. Before we get started real quick, I'd love to do the show of hands. Who here has heard of WebAssembly? All right, so for people maybe watching online that's like half maybe half the people in the room are kind of sparse here. But okay, I'll keep going. So in case you're very very lost and somehow ended up in this room and don't know what backstage is So so I kind of think of backstage this way you get to write code, right? You click some buttons Somewhere right computers get hot your code goes up. You pay some more cloud bills And hopefully your customers, you know, they do better, right? And and backstage makes this really easy whereas people would prior to now sort of cobbled us together with thoughts of other scripts and Sort of you know get a back shins and Travis CI if you're still there So why are we why are we here, right? This talk I want to introduce a bit of experimenting we've been doing around backstage and Making DevOps easier and trying to expand the plugins that are available for the backstage ecosystem. So right now backstage is essentially a large JavaScript app and To extend backstage you need to write JavaScript right just for both front end and back end plugins They sort of work all the same way Also, don't worry. These these slides are a bit text heavy and they'll be available after there'll be a QR code and a link for For folks to look at they're also on schedule. So you can check them out there But yeah, so the the main point here is really that we want to enable developers who don't write JavaScript to write extensions to backstage When when the problem of building a plugin ecosystem is pretty large, right? There are lots of ways you can do it Backstage is a JavaScript right to JavaScript application. So some of the more native options is stuff like v8 isolates There's always a the general sort of approach of virtual machines, which give you good safety, right? That's they're basically the the gold standard on on Isolation that we have available and then there is their approaches like sort of microservices based approach where you could You know theoretically do an iframe in the application and then you know push that off to microservice and then have have back-end calls Also go go there And the reason I want to add assembly web assembly to this list is it actually has a lot of Features and benefits from the top three and is a lot easier to deploy now with some of the changes that are coming in the ecosystem So I'm gonna I'm gonna run through very quickly what web assembly is It's it's deep, but this should be mostly all you need to know So the TLDR and web assembly that that should take you very far is that it's a compile target, right? So you write C code you get native code out, right? It works on one platform works on one stack sometimes even specific hardware and then you We switch to something like Java and what you do is you ship the thing that runs the code, right? You you sort of compile bytecode and that's what you get out But you need the JVM you need the JRE, right? Python code is pretty much the same thing web assembly is like Java or like Python in that you write code that compiles down to web assembly What you see here is the web assembly textual format, but there is obviously also a binary format So we generally just think of these as web assembly binaries This you can think of that if you've been around long enough you can think of this as the promise of Java But it actually works in multiple places more places than Java So this is a bit of a conceptualization of the of the Concept we just talked about there's lots of ways to compile right there's lots of ways to build the thing You're going to ship if you're building a native binary, but what? Web assembly does is it gives you a sort of intermediate Binary to ship as long as you have a web assembly compliant runtime over there on the right And you can run it from all these different languages and these are actually the languages that are best supported right now So you've got C C++ is There and this is really via clang. So this is really taking advantage of that tool chain You've got rust you've got go C sharp Python and JavaScript also typescript obviously which transpiles down and Right now the wasm runtimes that exist out there have really good support for many Upcom and actually risk risk risk vibe is not on here, but there's sort of support burgeoning for that as well So lots of architectures are supported and it's pretty easy to to deploy at this point So why if you remember going back a couple slides, there's all these options is isolates is virtual machines There's you know microservices right? Why is web assembly a good fit? Well, so it's sandbox. It's it's well sandboxed You generally have to give Permissions to do any sort of operation like you don't get by default access to the file system It's performant. So this is actually the I went to go look for the most critical sort of piece of research on how fast web assembly is compared to Running natively right and natively means a lot of things, but in this case, I'm thinking just think see right think is you know unsafe close to assembly language stuff and and Web assembly generally runs very quickly It's you know built for browsers and built in and built to work in what could be low low performance and low capability environments And I've put there for references Python is is very very slow compared to compared to native code So it really depends on what you measure to But but it's generally very performant Our web assemblies also cross-platform. So I've covered this a little bit earlier But the support for platforms is pretty good Even emerging stuff like you know risk 5 and and stuff that's coming up. Of course, this is all Specked out it's community driven and its standards driven So you can go to web assembly org look at the docs learn more about to secure the isolation performance and the platforms that it targets Going back to the so so out of the web assembly detour and back to the point of the talk Which is talking about how we can extend backstage with Plugins that are written in, you know non-java script languages We actually went ahead and tried to build this and well we succeeded which is why I'm here And as you know, there are two kinds of back stages backstage plugins nominally. There is front-end And back-end plugins and so they work very very similarly, but just slightly differently First thing we need to do is to create an interface on the end This is a sort of web assembly specific concept Well, I'll introduce it a bit more, but you can think of this kind of like gRPC if you've heard of that And then what we provide is a CLI that builds it installs this plug-in, right? So you write essentially a web assembly binary you run the CLI and what you get out the other end is a Fully built and again javascript compatible backstage plug-in and For back-end plugins are a little bit different right because they're basically web servers that live alongside backstage So so they're they're they're a little bit different, but the shell is the same We need an interface that sort of describes what a back-end plug-in is and a CLI that builds it and serves the request using the wasm binary that you gave it so There's there's a lot of there's a lot to This slide even though it looks very simple a web assembly interface types are a standard that builds upon the base web assembly standards that let you sort of speak in high-level concepts like strings and functions and Sort of more easy to understand types to the average average developer because at its at its core web assembly can actually only deal in Sort of computations on numbers, right? So like you see those there you've got like, you know sign 32-bit integers and things like that But with web assembly types the web assembly interface types, which I'll be calling wit from now on So if you hear wit you're gonna hear wit a lot, but that's what it means and and basically You see a simple logging interface there, right? So up at the beginning you've got the package And the first first bit of that is a namespace and the second bit is is a package name You've got an interface here, which is a basic logging sort of Interface and it's only got one function in it, right? It's got log it takes a string and it actually doesn't give anything back. It does something with that string That logs it hopefully somewhere, right? and The thing at the bottom there is the world which tells us the sort of interface to the binary So this means that this the binary that fits this interface exports so lets you call on it This logging interface so other things can call log on this binary right and so this is kind of like a binary-level Interface language or interface description language, which is why it's sort of similar to to gRPC One thing I do want to note to prevent confusion is that this interface language is not over the network So this is inside your binary inside your program at function call speeds, right? This is not you know by default going over the network and incurring, you know Json serialization penalties So this is that previous slide but but illustrated a little bit to make it make it a bit easier to understand So you've got your program sort of at the outside and you've got Your Web assembly runtime there's there's many of them at this point But the one that's kind of keeping up with the standards and helping to test out the standards is called wasm time So inside your program, you've got a Web assembly runtime in there And you've got a component that's written in let's say one that's written in rust and another one that's written and go and The way they can interact with each other or with the with the runtime itself when you execute them Is by this import and export system? So I'll go back a little bit Sort of the export that's here is sort of the the export that's the exports is pictured here And then there's another component that that is is built specifically to match that export So they sort of connect together. All right, so you don't don't try and read this But this is basically the entire specification as we've built it so far for what a backstage front-end plug it in So unfortunately, I can't save you from writing react code and having to having to write that in your backstage front-end plugins, but We can sort of formalize some of these ideas around dependencies and which files are sort of bundled right in the in the front-end Front-end plug-in sort of what is what does a front-end plug-in sort of consist of this is useful in and of itself because Especially in the previous talk. We had some questions around how can you sort of make it make a concrete? requirements on what people produce this plugins and this is this is sort of a way you can do that because the Web assembly binary that comes out of this you can sort of introspect it right you can ask it about itself And of course, you know there can it can lie, but but in general you have some some leverage there So I'm going to dive just real quick into what this looks like in regular rust code I'm going to take a step back. How many people are familiar with rust and it's sort of tool chain and have touched it All right. Well for reference. That's like four people out of this entire room So we're going to go through this very quickly actually Most of this is just normal just normal rust config like none of it is unique And this is Tamil for those who who aren't familiar But the two things that are important and sort of web assembly specific here are the Specification that the the crate type which is sort of like a package type in rust in rust speak is a dynamic library and The dependencies is our art is there's only one really dependency we need here Which is a project that helps to turn with definitions So what what I showed you earlier into code so similar to a gRPC generator or any other kind of like, you know Let's say an open a API generator That's what with by Jen is doing for us here And then down at the bottom is actually it's actually optional But what I what I'm telling rust there is that the target and essentially what it should build to is Wasm 32 wazi, which is just a sort of target triple name for web assembly with Wazi enabled I'll get to what wazi is later, but we're not gonna go too deep because it is deep For those who deal with it who don't know rust which is everybody except for four people This is probably not gonna be much But this is the what you see at the top there is a generated file So that's some of the output of that of that generator. I mentioned earlier And what you see below are actually some of the types that we defined Way back in the wit definition. So if I just go back Really quickly right here. So it's a bit hard to read But the the node dependency is kind of like an object, right that I've just defined there It's just called a record on there, but it's got three attributes or three members Let's say name version and whether it's a development Dependency so we see that that sort of comes that gets generated and shows up in our we can use it from our code So you see it as the sort of third import there? And then the struct that's a little bit to the little bit below here is like a it's like a class You can give it a class but without functionality, right? So just just data in it, but what we are going to do is hang functionality off of it So for the for the rust side When we specify the node develop dependencies, which was one of the requirements the code generally looks like this. It's Might be a bit hard to read if you're if you're not a not a rust station But it's it's very it's very simple if you look at the area right around the middle here where we just make a Vector of No dependency objects. We see that. Oh, we've got a dependency and it's it's called react, right? Of course we do because it's it's a front end front end plug-in at the end of the day And so that's that's basically what the the general code ends up looking like it's sort of implementations of this Interface that we said we were going to fulfill Right the the width interface and I'll skip over this But it's sort of you can sort of recognize it if you you squint a little bit You see some some TSX files and some component names and sort of specifying this is us fulfilling this contract again At the binary level, right? So now I'm going to jump into a little demo of the front-end building And build a backstage plug-in really quick here All right, I'm going to zoom in a little bit here. Hopefully y'all can see this Okay, that looks reasonably legible Okay, so here's here's that code. I I mentioned before maybe a bit more legible than before And as you can see it's sort of just a list of these node dependency objects, right? And sort of things you might recognize you've got backstage core components You've got some component files in here And this bill is pretty slow, so I'm gonna kick it off But first we're going to do is this is rust code We're going to build this rust code and then we're going to run the CLI That that we've been we've been working on here to to generate a Backstage plug-in so this is this is built pretty quick because I built it before this talk of course and this is again a Environment or and tool chain specific, right? So cargo components the thing that works for rust and for Python and for JavaScript You'll have different tools, but generally the first step is to build your code into a Web assembly binary, right? And that's what I've just done there. So now I'm going to run with a little pre-prepared command. I have here the CLI that we've been working on so you can see here that we are generating this sort of front-end plug-in We've given it an ID which is kind of a name like thing We've got a path to the binary and then what actually we also do is install the created plug-in into local, you know wherever your Backstage directory is on disk. So I'm going to I'm going to kick that off. This does take a little bit of time. So We'll I don't I don't think we'll we'll see how the how the Wi-Fi holds up here All right while that runs I'm gonna I'm gonna jump back here because the the front end is very similar. So I'll I'll let that run Okay, I'm sorry the back end is very similar so Here we basically go into the back end and it's a repeat of the previous slides because In actuality the interface is even smaller for a back end a Back-end plug-in But the interface is a lot more interesting. So towards the the bottom. It's a bit hard to read, but there is a Export that we haven't seen up until now called wazzy HTTP Now I'm explain wazzy very quickly and What it is it's a standard that builds on the original web assembly standards to encapsulate the functionality That lets you serve web requests. So doing things like making web requests and serving web requests So we've worked basically all the way up from just doing numbers in addition and subtraction to performing web requests Placing strings around doing all this And and this is one of the standards that makes that happen and makes it really really easy So we sort of start like at the top right we start with numbers and we add on interface types And they they give us interfaces at the binary level And then we add on wazzy and now we have reusable functionality, right? We have at the binary level at the at the web assembly binary level We have reusable functionality that is sort of a high level and abstract it This is also all Developed in the open right so if you wanted to look up wazzy HTTP and find out what was in it find out How it was specified you could actually just you know go to github. It's on there Breaking changes show up there, you know changes that don't break things show up there And it's easy to easy to sort of look through and verify and grok for yourself Let's check on That build there see if It's done. Oh, okay, so the backstage plugin has built This point if you feel like seeing terminal output, there's there's some there for you Oh, okay, actually, so there's you've got the the last yarn install So 90% of the time that this the CLI takes is running yarn And and because I do a sort of from scratch install to keep things sort of hermetic We'll wait for this to finish and load it into our our backstage instance Which is over which is over here? Let's do this So going through some of this it basically does some templating it takes the takes the wasm binary that I built before and Also changes your app. Yeah TSX One thing I'd I'd love to note about this is that we Generally want to try and find a better way to integrate that doesn't require sort of string manipulation in in these files, but you know, we're not there yet All right, so now it's finished. Let's let's boot up backstage here One thing before I do So these this is kind of a list of changes that have sort of happened right as a result These are the changes that got written into the backstage instance as a result of running that earlier CLI command So you can see we've sort of modified the package on JSON. We've you know mess with the dependencies a little bit We've got the app file the TSX file that we've changed and then we've got a new plugin directory, right? Okay, and soon we'll have just the you sort of standard, you know backstage backstage setup here And the idea of the plug-in Was example front-end example dash, you know hyphen front-end. So if we go there, we'll be able to We should be able to see it. We should be able to see our what we've developed here and That's it. So basically what's happened is we've built we've taken some time to build a web assembly binary in rust Generate essentially from that binary alone a backstage plug-in and load it into an active backstage instance Again front-end plugins just end up being you know react apps. So so that's what we're seeing. We're seeing here. Okay Yeah, so getting back here again, this is all developed in the open easy to find if you just you know do a little searching I'm gonna zoom straight through this because this is very similar to what you saw for the front-end But just back-end tailored right and again, it's it's at the binary level implementing the interface you said you would There's also also do a quick demo of the back-end because the back-end the back-end plugins are actually to me a bit More important because they open up your back stage instance to other services that you might be running Other orchestration systems. So they're a bit richer. I think in terms of integration capability So here's that here's that code. It's considerably more complicated mostly because of the wazzy HTTP integration So the way wazzy HTTP is written is essentially as basically as robust as you can ask for Something that deals with web requests just because it needs to cover many many types of types of things This is the end point. We're gonna hit later. So You can you can you can see it there. Hopefully hopefully we'll get to we'll get to execute that bit of code And yeah, I'm gonna I'm gonna go ahead and kick off the process at the bottom here Again execution very similar to before and unfortunately going to take a similarly long amount of time But it's you specify the plug-in type specify where you'd like to where you'd like to build and where your back stage Installation is and it will it will go ahead and put it in the right place I mean, all right, and what I've done there is just put the Backstage instance back to sort of default All right, and while that's while that's building. We'll we'll keep checking it out chugging along here So we've got a thing that works Well, I haven't proven the second part works yet, but at least some of it works And so what would we what what's left, right? Well, there's a lot left and what we really want to do is improve these areas that That we feel sort of hurt that the UX of like if this is ever gonna work We need better UX than than the current right we need better UX and just writing JavaScript and running it that way And right now what we what we want to do is make this loop a little faster Maybe try and get a tighter integration But it opens up a sort of a harder question, right? Which is can you in a more general sense convert any given react component to web assembly in a reasonable way that anyone will understand? Right then someone that doesn't have you know doesn't have to be a Front-end developer to understand there are frameworks that do this Like there are frameworks on the you know the Python side or the rust side that you can spit out Essentially HTML and DOM elements So it's so it's possible, but this is something we we need to look into more and build a good UX around Also, there is oh rather than sorry rather than using Changing the files by just looking for strings It just makes a lot more sense to do a smarter smarter manipulation of the backstage code And sort of I think a lot of that would enable more programmatic editing of a backstage instance Which I assume that roadie has down But but would definitely help the ecosystem we think And of course there's wiring it of more of backstage Resources like authentication and the database and I wanted to note here that that actually means writing more wit Right so that just means formalizing the interface And then wiring things up to sort of make the interface available at runtime to the web assembly binary So generally what what can you build right with this? Well, we'd like people to build front-end and back-end plugins with this toolkit and help us find the sharp edges Help us find us find things that don't work and could be better And right now as far as web assembly goes these languages are the best right? They have the best sort of bleeding-edge support for many of the features that are coming out So rust go JavaScript and typescript and so they're great places to start. Oh Let's let's go check on that a backstage plugin build now Hopefully hopefully it's done Okay, so the back the back end plugin build is finished And so let's we'll hop over to backstage itself the in the local install and I'll show you The files that have changed Okay, so a bunch more files have changed right for the back end for the back-end plugin There's a little bit more integration work required for a back-end plugin versus a front-end plugin But a lot of the changes are you know somewhat similar you've added maybe removed, you know modified some dependencies You've got the index for the back because back backstage itself needs to be modified right so inside the back-end Sort of code tree you have index.ts the typescript has to be changed and then you've got a new plugin Right, which is the example back-end in this case And then there's another little sort of integration file But in general it's really easy to sort of track this resource control and know what's changing when you run this When you run this and install something so we're gonna start the backstage instance here And then I'll do you know a web request or two to show you show you show you show that it works Okay, and we will not need this this tab it just opened up because We're just gonna curl All right, so here's that demo. Okay, so I'm sure everyone's probably familiar with this But backstage plugins for example by the plugin that I created is called example back-end right that was in the CLI Command and it's running, you know via backstage, but on port 2007 right so we're gonna hit that end point that get endpoint that we did we defined And see if we can if we can get it to to show up All right, and that's that's it so oh I'll take the clap. Thank you So trying to get into what this is doing will take a long time So I'm just gonna try and breeze through it But basically what happens is at the back end you build a web assembly binary that binary Is self-describing in that it's it says that it knows how to serve an HTTP request now What happens is we take that binary turn it into JavaScript So actually go back from sort of binary code right instructions to JavaScript code and then run that run that sort of piece as a server and Proxy through backstage to get to that running server Right, so it's a bit complex But the thing is the tooling for this has evolved to a point where it's still a little sharp around the edges But it's it's quite amazing What we can do with performance and like being with performance, you know not being lost completely and Quite well isolated and also with with high ability to self-describe and sort of be auditable So jump back in here, it'll be the last demo there Okay So yeah at this point you can build front-end plugins you can build back-end plugins before before I close up I want to just note sort of who's building this right? This is obviously not just one person or one company or just a couple companies, right? There's a there's a huge sort of group behind this And it's headed and stewarded by the bytecode alliance So you can and again they work in the open everyone's on zealup you can you can sort of chat with people there But this is this is they sort of move the move the the state of the art forward in this in this space I Stole this slide from a co-worker named Bailey Who works also with me at Cosmonic here and this is these are just some of the faces that sort of work on this Tech and sort of you know, write the compilers or write the debuggers and write the tests there are tests And lots of tests actually And this is you know, maybe not even a tenth of the people who have actually contributed over the years It's just you know, some of the people who are working on some of the the biggest chunks of it A special shout-out to the jaco maintainers guy Bedford is actually in here At the bottom left he sort of second from the bottom left there But a lot of how this works that that bit that takes the binary turns it back into JavaScript for again That might it could be anything right turns that back into JavaScript It makes it executable from a JavaScript context backstage in this case Is jaco, right? So this is basically me just reusing their work mostly and so so a big shout-out to them They do great work And just before I before I leave here I want to want to know why we is is cosmetic care about backstage and why we think it's a good fit For us and and we think that it's a good fit because in general if we can build in backstage support and backstage helps Teams and ops teams both dev and ops teams move faster Then as a whole we can ship faster and build more things that hopefully at some point helps some users So we as a company love backstage and we're really looking forward to playing more in the ecosystem and Doing more to improve do improve our support and supporting the ecosystem Thanks for listening Here's where you can find the code If you're very young look on the look on the left you can scan that and if you'd like to type you can Type in the thing on the right Thank you Thank you Victor. I guess we have time for one very quick question Who's the lucky owner? Was there a hand? Yes No, I knew I can always count on you Yes, yes, you can yes you can very quickly. Thank you. So Tied to be very quick. I love web assembly I think reliving the idea of dynamically link dynamically link libraries for ECMAScript is a great idea and I love what you showed for the back end component that totally works for me I completely don't get the front end part. So for me What you did is basically you put the TSX files into the binary resource section and then export them to To make them to build them through the yarn. So you could as well zip them. So why why to do that? Yeah, that's a great question and you're right. So the Web assembly in for the front-end part is a little less useful just because of how How the integration we're using right now have we have it design works But what you can't do with the zip file is sort of ask a zip file what dependencies it has, right? so like you can maybe you stuff up package.json in there, right and You know, maybe you like come up with something to read that and then change, you know backstage at runtime or whenever you're installing it But the problem is you also can't Verify the instructions that just sort of produce that right so like take a zip bomb Like you're out of luck now. So it's like there's it's a it's a slightly better Packaging mechanism and it gives you a little bit more leverage than just a regular zip file or you know, just npm install would give you And what we we think there's actually a better way to or sort of a more Integrated way to put these together and actually try and expose the render functions, right? so I alluded this to this to I alluded to this a little bit but Ideally we Put out a contract that actually gives you just HTML back, right? But then you have to do things like you know model react state machine and like you know There's there's a lot there, but we think that's possible. I mean, it's definitely possible. It's just matter of Yes, yes, no it could absolutely work on the GSX level and again, this is all web technology So it's it's there, but it's it's not it's not easy son. It's not easy v1 So that that's why we haven't done that far yet. Yeah. Thank you great great question Awesome. Thank you so much. Yes another round of applause. Thank you. Thank you