 Hi everyone. Thanks for having me and I'm super excited. This is actually my first actual talk about Mellify because usually I talk about other things and I'm just happy to share why Mellify is so popular among reactives. A little bit about myself. I go by Swift on the internets. I am one of the moderators on R slash React.js. If you want to learn about React, there's 150,000 of us learning and sharing and discussing and hiring each other. I'm also big proponent of learning in public, which is the reason I got started speaking in the first place. I also work at Mellify on developer experience, which is why I'm excited to share this with you because I think the developer experience is really good. The primary question I want to talk about today is really about as a React developer, what do you really care about doing in shipping your work to your end users? I propose that you care about cost, what do you care about speed, security, custom domains. You want some generic, random domain. You want some custom, nice-looking domain and some control over what shows up in the URL bar. As well as continuous deployment. When you check stuff into Git, you should want to have a very strong relationship between your source control and your deployment strategy. Unfortunately, when people learn React and deploy their React apps, there's a lot of accidental complexity. These are some articles that I pulled from unnamed sources. This is the kind of tutorial that you used to have, how to deploy a React app. First set up, first pick your SSH key, pick between 10 different levels of tiers, set up a drop rate, set your default user, and number the Tramod stuff properly you're screwed. Then set up a reverse proxy of Nginx. I don't even know what this is. The same thing goes on for this other non-unnamed competitor. You have to set up all of these guys, you first your theory, and then you set it up. It really just seems like a lot of accidental complexity. We wanted to get our React apps in front of users, and then we had to go through all this shit, or hire someone else to do it. It's really not something that we endure. This is something that I haven't even mentioned in all of this backend stuff. This is important. I'm not saying that this is not important. This is important for standing up services, but you don't need to do that for front-end development. You should have some sort of idea of separation and use of our resources according to your needs. When you care about it, notify tries to answer each of these for you. Answer the cost thing by the lowest cost possible, which is literally we put your sites on AWS S3. That's the cheapest thing possible. And anything dynamic that you run through service functions, we scale up and down per usage instead of having a constant build. Speed, we'll put everything on CDN by default and optimize your assets. Security, we must have HTTPS by default. What I didn't show you was those guys that I showed you. You get all the way to deploying your site, and you haven't even set up HTTPS yet because that's too complicated. You have to go and get your certification and all that in a smaller surface area. Custom domains, you should have a sort of DNS provider that's sort of seamlessly integrated with your hosting. In continuous employment, notify sort of answers that with the Git-based workflow. So I'll dive in a little bit. I don't have a lot of time, right? 10 minutes, but I'll dive in a little bit into each of these things in my demo. But the long story short is that notify gives JAMstack their superpowers. The whole idea is JAMstack, notify is a big proponent of JAMstack, but you don't need to use notify to do JAMstack, right? You can host it in S3, you can host it on GitHub pages, you can host it on Xite, you can host it literally anywhere. And that's the whole point, it's portability. You're picking the right level of instruction for building your apps. And so notify will live and die by its ability to serve JAMstack developers just like everyone else. It's a very, very even playing field. Okay, so this is kind of how I put it recently in terms of JAMstack and notify. Let me kind of put it. So before notify, setting up all of this stuff, it kind of looks like this. All the hoops that you have to jump through to get stuff done just to get like a best practices web app up, right? All of these things the guy's doing. And look at how happy it is at the end. There you go. And he's hosted a site. So that's not really the kind of developer experience we're keen on. So I just want to talk a little bit about some of the things that notify does that is unique to notify that they may want to know about. So for example, this very meetup that you signed up on, this is the React knowledgeable website, it also happens to be open source and it is a Gatsby site. So what basically happened is I went to the GitHub page and I was like, oh, I think this is a bit too white. I think it needs a little bit more color. So I opened up PRR and I changed something in the files. I said, here's a style of background color peach puff, which I was told is like a nice CSS color. And then I was like, okay, I don't have, you know, the ability to check this or like, let's say I'm a designer, I don't have the ability to code. I don't know what this looks like until someone spins it out for me, right? But notify automatically sets up deploy previews for every single PR. So all you do is just click here. You can see a deploy preview version of this new page, you can compare and contrast. This is actually how I work with my designer. That guy doesn't know how to code, doesn't matter because I can just give him a direct link to check whatever he wants to check. Responsive, publicly available, all that. What notify is doing behind the background is that every single PR, every single commit is tied in from GitHub into a deploy hook, right? So each of these deployers are built behind the scenes. And it's continuously built. So there is a build bar that you don't have to manually build on your machine. It's literally the only interface that I use is GitHub. I didn't even download it to my local computer. So that's the, it's this process of like, get this workflow as this process of like, put everything in your source control as a single source of truth. And then from there, you build your infrastructure out to support all of that. So when, when and if, you know, this is ready, or anyone else can just merge this in, right? And whatever, whatever was deployed here just becomes the current master. There's no difference at all between the test staging environment and the production one. And any time that you spend debugging that is just wasted time because the only thing you actually care about is production. All right. So a little bit about history of nullifying. And that actually has a studied sort of life as a maker loop. So the first thing that first thing it was started out as was what problems like a CMS thing. And then they realized a lot of people wanted to host their host of stuff. So it became bit balloon, which does simple drag and drop hosting, and eventually became nullified. So that's the story of the last five years. I just wanted to show you like the fundamental concept of nullify is no more complicated than the drag and drop. So I'm going to go to nullify.com says drop. This is, this is the, the old days of bit balloon. And this is how we used to deploy sites. I don't have a, I don't have a demo site ready. So I'm just going to download a prepared demo site. And I'm just going to drag and drop this into, into the box here. And what it's doing is just simply uploading that file that it gave me, right? It's already published. And I can just go here and see the deployed site. And this is a publicly available URL for everyone, right? So as a simple front end developer, you have the ability to just put in sites, upload it, make it publicly available. It's only the HTTPS. I can't zoom in, but notice that the green lock icon, you can set a custom domain for free. You can, you can version control it as well. And inside of, inside of this, this stuff, it's really, really very powerful. But this is, this is where nullify started life. This is just a CDN, just drag and drop. Then that's, that's a fundamental idea, like everything Jamstack, this is a static asset, and you deploy it to the nearest point of presence to your end user. That is, that's the theoretical limit of speed, right? That's, you cannot get faster than that. So that, that is the fundamental idea of nullify edge, which is like, you know, you deploy everything to the edge and then, and then do all your server assets there. I also showed you nullify build where, you know, every time you do something in git, it gets continuously deployed into, into, into master. And then the last thing I should, I should probably show you is nullify dive. So out of the three pillars of the company, this one is the latest and newest. That's why it's beta. I happen to be the lead CLI dive on this when we launched it this year. And this, this is the whole idea of like, let's keep going backwards in your development flow, right? Okay, if nullify edge took care of your deploy, nullify build took care of the continuous delivery, what about your development stage? How can we make it better there? So for example, if I was, if I was doing this, I still have to wait for the continuous deployment, you know, machine to run out to spin up and spin down. There is, there is a bit of lag time and that just kind of breaks your flow a little bit. What I've done here is, oh, by the way, I'm going to ask you to use your phones in a bit. So if you want to connect to the internet, you can connect to strike guests on the phones. So what I've done is I have this, I have this, I clean the repo locally. And, and it's a, it's just a local repo. One of the, one of the interesting things about this is that it has a, it has a serverless function just like Thomas was mentioning. So I have my, I have my React repo over here with all my components and pages and templates. And a serverless function has, has all the, the node side stuff. And the primary reason we want to use this is because I don't want to expose my secrets to, to the front end, right? If I, if I'm a front end developer, anyone snooping my browser tools can actually see the, the secret. So I want this to only run on the server side. Does that mean I have to spin up a full server? No, because I can just proxy it through a serverless function. The only problem is then I have to deploy this to production every single time and, and get that running. So essentially I need, what I need to do is, is local emulation. So I'm going to run that if I dev, and I'm going to cheat a little bit by running that if I dev life. That is a CLI command. And this, so what this does is it runs the, the local source, sorry, the, the app locally as well as sets up a Lambda server that, and proxies both of them together. So we have a, a full stack replication on your local machine of your, of what, of what your app should look like. So I'm going to let it go for a bit. This does take a while, which, which I'm a little nervous about. And we're about to use public internet, which again is another source of risk, but that's what makes life interesting. Okay, so, and while I, while I, while I sort of kill time, this basically hits an air table back end, right? This is how the react knowledge will meet that site, knows all your RSVPs. It sticks everything into, into, into an API. Okay, so this is building at the back. And this is, so this is built live. Please be, please work, please work. Yeah, okay. So, so this is a fork of, of, of, I just added the word fork in, fork inside it. And, and so the whole idea is that it's, it's able to pull, for example, from here, my air table back end. Let me just click there. Am I able to click? Please work. Okay, hang on. Let me, I should probably show you the air table. Okay, so, I'm not sure what, I'm not gonna try and debug right away, but I'm supposed to be able to click here and kind of go through, go through with that. Actually, let me, yeah. Okay, I'm just, I'm just a whole host 8888. Local host 8888. Sorry, my machine is kind of eating, eating up itself. Okay, so, so it's actually pulling from this, from this air table back end, via this serverless function. So it's, so, so, so for example, let me, let me just try and show you in the console. If I can, if I can do it well enough on speed. So if I, if I do like, yeah, I'm just gonna do Stripe again. It's actually going to, going to simulate that the API responds in the back end and actually add it into my, into my database. And all of this is running local locally on, I'm on local host 8888 right now. And it's, and it's showing up. So, so I have a local emulation of that, of both the front end and the back end, which is very important for, you know, for high fidelity testing. And the last thing I want to show you, this is the, this is the actual beta feature. So, for example, if I wanted to work on this live, so currently this project is working in development, more live on my laptop. And I wanted to show you how it looks in, on your device on, to my product manager, to my designer, I can actually share the URL and they can see it on their machine as well. So I'm going to stick it into a QR code and let you guys, if you, if you want to take a, take a, take a quick photo of that and measure open up in your browser and you can see, again, this code is running live on my machine. I haven't deployed it yet, but what I, what I really want is to take advantage of VX hot reloading features, right? And, and that's, that's the, that's the really fast pace of, pace of development. So over here, I'm on the same page that you are. I'm on the same page, is everyone loading this directly? Yeah? Okay, cool. So I'm going to edit this style again. Again, I'm not making a PR, this is running locally. I'm just, I'm just adding that in this style that I, that I want to, that I want to demo for. And the whole point is to try and push it out to everybody. On your phone, you should be seeing that live updating feature. So the whole process is get this in, get into your development process, get it out to your, your, your stakeholders as fast as possible. When you're happy with it, commit it, get it deployed and get it out there. So reducing as much incidental capacity as possible. That's the whole idea. All right, last, last bit. So, so as you can see how notify evolve from the edge, edge service to a build service to a dev service. Your code is actually, we're actually trying to trace in your code backwards from, from developing your code to building and then deploying. And so, and so hopefully that, that makes a lot of sense. Final pitch as to like, what kind of people use notify, notify? Obviously, React.js.org uses notify. Redux, as well as the firmware that we won't mention. Um, um, um, uh, content science expansion magazine, Citrix, which I, I, I personally don't use, but you know, they're, they're a really, really big enterprise. And then Sequoia Capital, which actually is one of the few VCs that don't invest in, in notify. So, um, but, uh, so marketing science as well is really, is really, you know, it's a really good model for, for serving marketing sites. Uh, uh, and you know, especially for spiky workloads, for example, like election day, uh, you might have very spiky workloads. You should have static assets instead of overloading your servers and scaling up and spinning down. Who cares about that kind of thing? Just, just put it on CDN. Uh, e-commerce as well is, is proving out to be an interesting use case. I think people here are familiar with Popeyes and they, they handled a lot of learn recently with Netlify, which is, which is really, really great. Uh, just a e- retail commerce thing in, uh, company in, in, in Canada. And, and they had a recent, really good talk at the recent Jive Stack Conf as well, which I highly recommend people, people watch. Uh, as well as Perotem, the, the, the bike company in which, uh, strong fans of Netlify as well. Um, X-Rise is a little bit, uh, more interesting, right? Because like, you have to, you have to, like, make still static nature with the dynamic nature. Um, so I, I would talk about PayPal, even though they're not a Netlify customer, they actually investigated Jive Stack a lot. Um, and because the PayPal, because of their financial needs, they don't, they, they ended up not using Netlify because we didn't have talk to certification at the time. But, uh, they went and built their own Netlify infrastructure and PayPal about me is now on Jive Stack. Uh, Gatsm is still, if you, if you contribute to Gatsm, you will buy any stuff from Gatsy. That's a working open-source e-commerce app. And you can actually see how they, how they implement, uh, you know, dynamic apps on Netlify. And of course, uh, Netlify is implemented on Netlify itself. So everything authenticated, uh, you know, deploy transactional that you can do, uh, with, with a regular site, you can do Jamstack and you can do on Netlify. Um, so if you want to learn more, uh, there's a, there's a, there's a free e-book that there's, there's just been published modern-world development on the Jamstack and that's the QR code for that. Um, and if you, uh, want to step-by-step tutorial, I actually recorded a three and a half hour, uh, YouTube video. Um, just walking you through how to use every single feature in Netlify. Yeah. Ha, ha, ha, ha, ha, ha, that took a month. Um, anyway, that's it. Thank you so much.