 So, welcome. Thanks for being here for my talk today. My name is Andrew Gerard. I'm a software engineer at GoDaddy. I've been with GoDaddy about four years. And today I'm going to talk about Gaskit, the framework maker. So, before GoDaddy was a technical artist in game development, as a tech artist, I would build tools and processes for artists to build the craft and integrate their assets into games. Now, as a software engineer at GoDaddy, I have a similar role, and that is to help build tools and processes for web developers. Now, GoDaddy's vision is to empower everyday entrepreneurs to build up their own businesses and establish an online presence. And GoDaddy is not just in the domains business. We have silver products. And for customers to build their businesses with, many of these products are in the form of customer-facing web apps. But we also have several internal-facing web apps for help developers, help our organization, and our customer care agents. Variety of different use cases. And so, we built something to help us develop all these apps, which is what I want to tell you about today. It's a really cool project. We're announcing and releasing today as open-source, which we call Gaskit. Now, before we get into the nuts and bolts of what Gaskit is, I want to lay some groundwork. And for the structure of the talk, I'm going to first describe the problem that we're going to answer with Gaskit today. And then point you to some ways you can use Gaskit yourselves and get involved with this new open-source project. Okay, so, what is a framework? Before we dive into it, let's consider what a framework is. According to Marion Webster, it's a basic conceptual structure as of ideas or a skeletal open work or structural frame. To summarize that for our purposes as software engineers, it can be said that frameworks provide a foundation for software developers to build applications in a streamlined way. Okay, so how are frameworks made? To start with, I just kind of want to see where you guys are at. Who has worked on frameworks before or actively builds them? Okay, and what about just Node.js apps, web apps, or otherwise? Okay, so let me make an argument here and kind of prove a point. If you've built an app before, have you taken that app and built another app from the same ideas or the same kind of code base you've done before? Okay, in general, you could consider, basically, you've made yourself a framework. And let me walk you through kind of this process and just to kind of see where I'm coming from here. Okay, so I'm a visual person. I put together some visuals to help illustrate the concepts I'm speaking about during this talk. So to start with, let's say we have a box. And this box represents our app. Okay, now we're going to build a front-end web app. And let's pick out some libraries we want to use. Okay, maybe we're using React for our renderer. Maybe we're using Webpack for our bundler, Express for our survey engine, so on and so forth. Okay, finally, we need to get all these integrated together. So we write some code, time all together, implement our app, and we'll say this is our app. Okay, now we've been tasked to build another app. Okay, instead of doing all this work again, probably what we'll do is just make a copy of that app and change up some of the application code and then we have another app. Okay, so we repeat this project in this process because we are, you know, app-making machines now. And, but let's look at some of the problems with this approach we've taken. Okay, say we find a bug over in this application, somewhere in the integration code, and say we make that fix. Now, ideally, we make that same fix across our other different apps that we have created. Okay, we go through and do that. And now it's kind of hard to see in my visuals where the changes were made and if I've missed an app. The same thing's true with our code in our real apps if this is the approach we take, going in and touching loose code within our apps to get these things work to fix, to make a bug fix. Another thing to kind of point out, it's hard to tell integration code and framework code from your application code. It's all living there in the same pool, the same mess. Okay, so let's look at a problem, a way to kind of solve this problem. What we can do is take our libraries that we've chosen and introduce a new framework package. Okay, this would be like a, you know, just a standalone NPM module, okay, that our app depends on all our libraries are part of this package, all our integration code lives in this package. So now we have a clear separation of where application code ends and where our framework code begins. Okay, and with this, we can, we can separate our framework from our application and it's much easier to spin up multiple applications using that same framework package. This time, if we find a bug in our integration code, it's just in that framework package, we make the fix and from there, we simply update our apps with that framework change and it's very clear which apps are on which version of the framework. Okay, so frameworks are useful in a variety of ways. What we've been talking about is, you know, centralizing our common code so we don't have it scattered through all our apps. And this, it also allows us to standardize what features and libraries go into our app. Okay, another benefit, it gives us a uniform way to develop our apps. We have a common patterns in place that we can, we can build from. And this ties into cross team collaboration. So, same team A is tied on a deadline and team B has some availability so they can send developer over to help out with team A. The developer of team B already knows the framework, already knows how the apps are built with the framework. It's very easy for him to onboard and help out with this other app. And of course, you can add to the drive principle. Don't try to solve the same problem multiple times. All right, so let me, let me tell you a little bit about how frameworks play a part at GoDaddy. But before I do that, let me, let me start with, back when I was a tech artist at a game studio. Okay, so as a, as an educational game company, we develop a pattern for assembling games quickly end to end. And part of that, which was my responsibility was to build a, a framework for a web-based game editor, which depending on the game, different game features could be tied into. So we had a web app in, say the, the blocks on the right represent different game features. Now, depending on the game, these features could be removed or replaced, depending on the needs. And we were able to iterate and build games much quicker this way. Okay, besides, besides the, the editor itself, you know, we had the, the, the game engine part and the server parts to, they all kind of followed the same principle. Okay, and so then one day my former manager, who I had worked with on this game development pattern called me up. He had left a while back and was now working at GoDaddy. And what he wanted to do is bring me on to help build a web app framework to tie different hosting products into. I think my first response to him was like, what? GoDaddy? What I want to order for GoDaddy? But after a while, one thing led to another and eventually came around to the idea. And GoDaddy's been great. I'm not building games anymore, but there's plenty of problems and challenges to solve, which makes the work interesting. And I get to work with a lot of really smart people. Some of them are in this room today. And when I started there, I was with my former boss, now my new boss, and we were in GoDaddy's hosting organization. Okay, GoDaddy has several hosting products and the web apps for these different products were scattered. The experience was scattered. They were built with different tech stacks. You know, teams weren't really communicating with each other. So it was just a bad experience for customers. Basically, they were all in different technology islands. And so what we wanted to do is try to break those down and have one pattern, one process, one framework to build our hosting web apps with. So what we did is similar to what I described before. We started with an app shell, built our framework package. GoDaddy was standardizing on React at this point. So React was one of the libraries we chose. And internally, we also had a team working on UX components with React. So we used that and helped contribute to that as well. We used Webpack for bundling. And as part of this framework, we had a way to tie in the different hosting products so they could develop their user experiences independently but still tie into this cohesive application. All right. So this worked well. And we soon had other apps besides this hosting app using it. Somewhere in internal facing. We had a couple customer facing ones as well. So eventually, our small team was moved out of the hosting org and rolled into is called App Services, which was provided services and support across GoDaddy. We were excited by this shift as our small team and eager to take our framework to other teams across GoDaddy to build their front-end web apps. But what we found is that other groups had done some other things, building their own frameworks for their own apps, okay? And this looks familiar, right? If you zoom out from just where we were at at hosting, all of GoDaddy was essentially on these different technology islands. Okay. So clearly what I've been describing, it's a real problem. Not just for GoDaddy, you know, ran it to this in the game industry. Imagine it's common to all companies, anybody that builds multiple apps with has multiple teams. Okay. Now, teams need frameworks to build their apps. Okay. And we just saw there's many benefits of doing so. So how are we going to handle this at GoDaddy? What did we do? What we did is identified the three most commonly used frameworks. And we took a few people from each of those teams and we formed a Tiger team within GoDaddy, cross-organization, just to kind of try to bridge that gap across organizations. This one, we decided to name our project Gaskit, because if you think about it, Gaskits are, you know, in plumbing and mechanical engines. They're what bridge the junctions or seal the junctions between pipes and fittings. And we thought as Gaskit is doing that for our libraries and our feature code. Okay. So we didn't just do this in isolation, just in this Tiger team. What we did is we started out with a request for comments process with proposals, gathered questions, gathered feedback from other developers who were going to be using this new framework. And, you know, ideas and opinions are like armpits. Everybody has more than one. They all stink, right? So we worked through that. We started deciding which frameworks to keep, which ones to not use, what features to use. And during this process is when we learned about Next.js. Now, Next.js is great. It took care of a lot of our goals. Tying React in with server rendering, with web pack bundling, and gave us a routing solution. And, but it didn't solve, it was one piece of the puzzle, but it didn't solve the whole thing. We still had to handle authentication, particularly to GoDaddy. We still had to tie in our UX platform, the UX components I was talking about. There were still several pieces that we needed. So we still needed to have this one GoDaddy framework thing, even if Next.js was just part of that. So once we decided all that, we started into the building the framework. Now, what Gaskit ended up being is not what you may have expected. It's not the teal rockster or green boxer. As we got started, some of our team wanted to implement a plug-in engine with a command line interface. Honestly, I was hesitant with this notion at first. We already had a pattern, like I just demonstrated visually, for building frameworks. Why do we need to do this different? Are we over engineering this whole thing? However, as we continued to work on it with our new cross-organization, Tiger team, it clicked. We weren't just building another framework. We were building the tools to actually build frameworks, and I will illustrate that shortly. So once we reached that and it just clicked, we knew we had to get this out to open source. This wasn't just solving a GoDaddy problem. This is a problem that other teams, other companies can make use of if we get this out to the open source world. So what is Gaskit? So the project turned out to be not just another framework, but a way to develop frameworks. There are some essential elements used to compose frameworks, and I will walk you through those next. Okay, so there's six key elements. The CLI, which has the plugin engine, plugins themselves, commands, life cycles, hooks, and presets. To start with, let's look at the CLI. This is the entry point into creating apps and interacting with apps. So you type Gaskit, this name of the CLI, and the first thing it does is loads plugins configured for the app, or if it's a new app, it has some built-in ones, built-in plugins. Plugins are the building blocks of an app framework. They provide the scaffolding, the circuitry, or what you use to integrate libraries, and they communicate together, which we will see in a little bit. Plugins also make the commands available to the CLI. You can use plugins to add commands to your CLI. In this case, in this little example, I'm going to show you the create command. Okay, so commands are the first argument to the CLI. When you run create, what it's going to do is fire off various life cycles. Okay, life cycles you can think of as the nervous system of your app. That's how different layers, different parts of your app communicate. These aren't your typical event emitters either. These can be executed in various ways, and they can be handled in order, okay? Very important, but what handles life cycles are hooks. Hooks also are made available by the plugins that you plug into your app, and hooks can also execute additional life cycles. Hooks are where you implement your integration code and your feature code that you want to use across your app. Okay, so this is kind of high level. Let me give you some concrete, little bit more concrete examples with the create command. We have a prompt life cycle that gets executed. Prompt, for example, when you're running running create, it allows plugins to ask the user questions. For example, when you're creating your app, what's the name of your app? Do you want a Git repo initialized with your app? Do you want a test suite installed with your app? Do you want to use Yarn or NPM? Things like that. Okay, after the prompt life cycle, after the all it's all gathered, then we enter the create life cycle. This allows plugins to set what files are going to be generated for the app. It allows them to say what dependencies they want to add to the package JSON file, other things along those lines. And then at the end, we have a post create life cycle. This gives the plugins the final layer to do any fine tuning to the app that as it's being created. For example, with the lint plugin, you can run eslint fix. It'll match up all the generated files to the lint code style that you've chosen with that plugin. Okay, so the last key element with gasket are presets. So presets are basically collections of plugins, additional configuration as you need. And these are loaded by the CLI, make plugins available. And basically presets become your framework. They're the chosen set of plugins or features that you wanna have in your apps. And you share presets across your apps, which I'll point out a little bit better shortly. Okay, so back to this example. Instead of now, depending on the Slart's framework package with our libraries integrated together, what you're gonna do with gasket instead is configure at your apps with plugins. Okay, plugins layer together and they can have dependencies on other plugins. And for example, here next depends on the webpack plugin. And I'll explain that a little bit later. But let's say, let's say for example, we're not just building a web app here with NICJS. Say we wanna build just a microservice or some kind of API, REST API. You can remove those other layers of plugins and just have HTTP with Express, okay? Plugins are also designed to be interchangeable. Say I don't wanna use Express. Say I wanna use Fastify, which was recently announced as part of OpenGS Foundation. You can do that, you can swap these out. And I could use Fastify back with NICJS and my webpack plugins, okay? So plugins can be interchangeable. And besides just that, think about what if, go to as a React shop, that's fine, that's great. But as we open sources, we expect to see things like maybe a Svelte plugin, maybe a Rollup plugin. We're not tied into one particular bundle, one particular renderer, or a compiler, whatever you wanna refer to it as. So besides plugins for, well, let me take a step back here, sorry. Let's go back to GoDaddy's current tech stack. So we have Express, Next, Webpack, Redux. This is what most of our apps are using right now. These are library plugins. You guys know these names, but as I mentioned before, we had internal needs as well, our auth, our UX. What we have is internal plugins for those as well, okay? So plugins aren't necessarily just for tying in a library that you wanna use from the open source world into your app. You can build your own plugins for your teams, for your companies, and integrate them with the Gaskit setup. Okay, so when teams have settled on what features they wanna have in their apps, what you would do is stamp those into a preset. So now whenever I go to create a new app, I would say, okay, I wanna do Gaskit Create with the GoDaddy preset. That's how we spin up apps at GoDaddy now with that. Pre-sets can also represent smaller sets of plugins that make sense together. So for example, if there is a Next.js preset, which we have in our open source packages right now, so you guys can kick the tires on Gaskit quickly. And so we have a preset for just progressive web apps, the different plugins we need for that. Those are available. Apps can be composed of presets, like I'm depending on two here, and presets can also be extended. So if your team wants to use the Next preset and they wanna use the progressive web app preset, you introduce some other plugins for your own teams, your own companies, you can do that and have a higher level grouping of presets. Okay, and so as you can see here, what was once a framework package that could not be changed, could not be played around with, experimented with, you know, trying out Fastify, instead of Express, you can now with Gaskit piecemeal these together and build your frameworks in the form of presets. Okay, so this is probably a question you're thinking right now. Is this just another app generator? Is this like, you know, besides, is this more like Yaman or something, Yaman? The answer is no. Gaskit is also used for runtime integrations in your app as well. We've been talking about how you create your app, but let's look at some examples of how you use the Gaskit life cycles during your app or when your app starts. So we're gonna look at the start command and let's walk through this now. So we have the Gaskit CLI. In a context of our app, it's going to load plugins and we'll say the start plugin is made available. Start plugin gives us the start command. When I execute the start command, it's going to fire off the first life cycle, which is the start life cycle, okay? Next, the HTTP plugin hooks the start life cycle and it executes a create servers life cycle which allows plugins to say, okay, this is what I want to go into the server that's created. In our case here with that GoDaddy stack I showed you, we have express, okay? Express hooks it, express says I want to be the handler for the server and as you know, express can be used with middleware and you can set up your routes and one up for it. So the express plugin executes a middleware life cycle allowing other plugins to attach middleware and also executes an express life cycle allowing the instance to be manipulated add your routes here, things like that. The next GS plugin then hooks the express life cycle and it sets up the routes for the pages of your next app, okay? This plugin then initializes Webpack which is hooked by the Webpack plugin, okay? When you do that, that allows other plugins to either use the Webpack chain life cycle to assemble Webpack chain or Webpack in a chainable way and there's also another Webpack life cycle allowing plugins to return Webpack partials that get merged in or mutate the Webpack config at that point and again, these life cycle were ordered. I'm not showing all the nuances of how you can make use of these, we're just kind of going through the initial parts here. Okay, so once the next JS plugin has gotten its Webpack config, it then executes the next config life cycle. This allows you or your plugins to manipulate the next config, use some other configuration plugins like Next SAS or Next SCSS, that kind of stuff, or CSS. And so that's an example of a flow with the start command. There's several more life cycles you can make use of in your apps. As you add plugins, you can add your own life cycles and you can create your own commands, okay? We've been talking about start, there's other commands available and again, you can build your own. You can see what's available today if you go to our Gaskit Devs doc site. And speaking of docs, let's talk about that. So the key aspect of any good framework is this documentation. You want developers to use your framework, not get lost in the code, trying to figure it out. Your documentation should be clear. And since Gaskit allows you to build your frameworks in the form of these plugins, in the form of these little individual components that you compose together, how are you gonna present docs for your apps for this? What we've introduced with Gaskit is a docs plugin. Now the docs plugin makes available a docs command. So when you run this command, what it will do is collate all the readme files, all the documentation files of the plugins installed for your app, put those in a central place, fix up the links between readme's and there's also a docsify plugin which will then give you a nice web view of your documentation. So this would be the documentation for only the plugins and presets and what's available in the app, not just not the whole ecosystem. So it's pretty cool. If you guys have played around with Rust, this is kind of like cargo docs, it just gives you the documentation for what's in that app that you're working on. Okay, so who is Gaskit for? Obviously it's for developers. If you're an app developer, you can use Gaskit to get at the life cycles, integrate your own features, tie in with other plugins. It's also for teams. Okay, if you're building multiple apps, you have multiple teams working on these apps coming down with a tech stack you're happy with, a pattern of development you're happy with, put those into a preset, share those across your team and you're good to go. Gaskit's also important for communities. I mentioned Next.js, I threw out Svelte. Any of these kind of communities that the build up libraries, they want their libraries to be able to interact with other libraries out there. If they're in the form of a Gaskit plugin, it makes it easy for app developers, for teams to try those libraries out in the context of their app and their context of what they want to use for a framework. Okay, so next question, how do I get started? So to get familiar with Gaskit, the Gaskit project and what's available today, invite you to visit our website, Gaskit.dev. This is a docsify site using GitHub Pages generated with the Gaskit docs command, okay? So you can kind of get a feel of how that works. We have a nice splash screen on the front, but it'll give you an idea there. And the best way to get to try it out is to kick the tires with it. You can install the Gaskit CLI today. We just pushed that to npm last night. So give it a run. The help command will show you what you can do with the different commands. And so just as a quick recap, developers need frameworks to build our apps effectively and quickly, right? Gaskit provides a tooling to build fully-featured frameworks, docs, starting an app, not just creating an app, okay? And the Gaskit ecosystem, it's ready to grow with your contributions to the open source world. Help us out, join in to the fun and let's make Gaskit a real thing, not just for GoDaddy, but for everybody out there. And if you have any questions, you can grab me on the hallways or hit me up. My name's on Twitter, it's CanetteFX. I didn't put it on the slide, but just fire me or when I let her go to GoDaddy guys and we can get you to go on. So thanks.