Serverless for React Developers

I would like to start with... so just an overview for you, the plan is to build a project, an open source project. This project is not going to benefit me or my company in any way. It's just to learn together. And it's a workshop.

By workshop, I mean we're working, but we're doing interactive shit. It's not like a three-hour-long talk where you turn off your video and fall asleep and then come back at the end to say, wow, great job. Meaning it's misnamed. It's a lie, is what Wikimedia says. And the presumption there is it's a lie because there's actually servers.

So it's not server-less. But really, serverless is named as it is because to you as a developer, it is serverless. You're not the one managing the servers. You're not maintaining the servers. You're not scaling the servers. You're not implementing strategies for failover for the servers. So for the developer, it is serverless in that you never touch a server. Instead, what do you touch? You touch an API. Literally an API, an application platform interface, an interface into someone else's server. That is it.

How does it connect to React? React is a level of abstraction on the imperative browser DOM, the document object model. Like React is just a bunch of functions that have state that map to elements in your browser. Serverless is similar because serverless is nothing more than abstraction. The servers and their complexity are abstracted away. You could put React as JSX in JavaScript to model the DOM. There's ways you can also model servers without actually having to deal with them.

Excellent. From what you wanted to learn, I received that, Matt. You mentioned you wanted to learn strategies and recipes and cookbooks on building with serverless. I think that's really helpful. Because I wanted to do this workshop in a way where you can choose your own adventure. And there's usually two ways this can go. I'm gonna need you to pay attention here. Because this will literally affect the entire workshop. You get a very different workshop if you fuck this up. It can either be... We look at serverless under the hood. So we build, maintain, provision, scale servers. And so we kind of understand serverless from that way by actually creating servers and doing the work that AWS would do. Or we use existing serverless solutions and compose them together in a React app. The latter is definitely more React-focused, less like backend infrastructure-focused. And will actually give you, I think, in my opinion, more transferable-slash-useful skills in the modern front-end React world. Because how people build apps today is, for example, if you're building a React app, you'd probably connect to Auth0 for authentication. You'd use some type of serverless database, like Zada. You'd compose different serverless providers. And then have your React app also server render or serverless render in its own way. So there's rendering strategies and things that React can talk about that would help you more meaningfully. The other one is more information that you learn about how things work. But you probably will never use professionally because there's people who work at AWS that's their full-time job, okay? So if that's clear, pick your own adventure by writing in the chat one for the serverless behind the scenes and two for composing serverless things in React.

Shit, unanimous. Awesome, good. That's, okay, I'm seeing way too many. Yes. Could you please repeat the options? It's a bit misleading. Yes, no problem. Option one is we use things like Docker and containers and build our own, like, poor person's platform as a service, where we essentially, like, recreate AWS to understand the complexity of servers and provisioning them, scaling them, and so on. Versus option number two is we just build a React app and compose multiple serverless solutions. I think even though I repeated it, I feel like number two is, by far, the most common And that is what we will move forward with. Excellent.

To do this, here's the project. So again, it's highly collaborative. Also, I think this project has 16 or more features. Let me just share my screen, actually. And make this... Now that we have a direction, let's just go full workshop. By the way, feel free to interrupt this workshop at any time. I have a tendency to talk a lot because I'm first a speaker, second a workshop instructor. So if you wanna interrupt, there's a good chance maybe you won't even see the chat or your hand raised now that I'm sharing my screen. So open your mic and speak. I will not let you, I will not silence you. I want to hear you. Sorry, Ritwick, you're the minority. We're not doing that, but I'll just do that other workshop, in a second, somewhere else, maybe. Cool.

So this is my entire desktop. Hopefully there's nothing confidential here. The Project, let's open that. It's actually a GitHub repo, so if we go to my GitHub, this should be pushed. Your step zero is to clone this repo. So it is the tagesq.io slash serverless workshop. You'll want to fork it and clone it to start with. Okay, so you're gonna do that. I wonder if I can just have everybody collaborate here. That would be awesome. Because then you don't have to- Maybe you can drop a link into chat. Sure. Yeah, I would hope that you don't have to fork it. That would be awesome if you could just, but I don't think GitHub allows that. Yeah, let me do that. How do I get back to the, ah, chat. Excellent. This is what you're gonna fork and what you're going to clone. We effectively now have, 20, 21, we have, like, two and a half hours. What are we building? You'll wanna watch my screen for this. STRIPE Home, has anyone heard of STRIPE Home? If you have, raise your hand. Okay, good. Nice. We're on the cutting edge. STRIPE Home is an amazing tool for companies of any size to know their teams, their colleagues, their friends. It's really great, it's just a portal where you see people who join the team, whose birthday it is, you see a shared calendar. It's really nice. This is our project because it's not open source and it bothers me. And I used to work at Spotify. Spotify has 5,000 plus people. And something like this would help you get to know 5,000 people a lot better than Slack or Confluence. If you've used Confluence, I'm sorry. So the project is, we'll build this but with serverless technologies. Again, it's open source. So I gained nothing from it, you gain nothing from it. We're just building. If you're not comfortable building a collaborative project, you don't have to. Some people are like, wait, are you gonna monetize this? No, it's MIT licensed and will be and so on, but it's just to learn. With that, this is the stack I'm thinking about. If there's any objections, this workshop is so you learn stuff. And if you're bored of like Tailwind or you wanna use Chakra UI or something else, now's the time to interrupt me and voice alternatives or more than happy. This is about learning things we've been seeing on Twitter but maybe haven't got the chance to use. And I know that it's hard to get time in your day-to-day life to play and you don't wanna do this stuff on the weekends. So now's the time to play with cool shit. Okay, so cool, I don't see objections to this. This is awesome. If there are, the chat is your best friend. I'm actually looking at the chat. Good, these are the features for the product categorized by what's needed and what's just fun and what's maybe too complex. If we get here, I'll be really impressed to be honest with you. I don't think we're going to do that especially not given the time. But it's an open-source project. So if you wanna keep learning and keep playing after the workshop, be my guest. But we'll start here, we'll add signup log. For something like this, you probably need authentication, right? So we'll do signup log in a user, the ability to upload a profile picture, tell us about themselves. Anton, what's up? I was willing to ask, we would afterward deploy it somewhere serverless, right? The whole thing is serverless. Yeah, it's all composing many different serverless providers, exactly. Aha, okay. Cool. Yeah, so if you can put your hand down, that'd be great. Yeah, so that's a great question. I should have maybe outlined what serverless providers we'd be using. So in terms of serverless, you know what? It's a workshop, let's just edit the read me right here. So let's maybe go here, the serverless providers. And what we'll do is hosting is we'll host on...

If you have different opinions, now's the time. I'm thinking hosted on Brasel, one of my favorite serverless platforms in the whole world, and abstraction on top of AWS. So if you want to use AWS, cool, but potentially unnecessary because Vercel is like a nicer layer on AWS and requires no credit card. So for the workshop, it's probably better than putting your credit card in AWS and so on. Again, all of this is interruptible and customizable and we have the time, okay.

We host it on Vercel, the data store is of course, Zada because I work there and I know it better than any other data store. I think that's it, really, I mean, those are the only servers we need, a router, so a client-side slash server-side router, that's Vercel and a place to dump our data. If there's anything more we'll add to this list. So now I'm going to, yes Arslan.

Hey, so I'm new to serverless, so I was just wondering, as a part of this workshop, can we cover how you would debug through different serverless code? So normally in a REST API, you just throw the debugger around and kinda figure out where things are breaking. But it doesn't make sense to me how that would work in serverless. Yeah, definitely, we'll spend some time, because with serverless, you usually need to set up something called a log drain. Because you don't really, like, logs are expensive, there's just tons of streaming strings, and providers don't wanna accumulate that much stuff. So, yeah, we'll set up a log drain and everything. Julio, Julio, Julio? What's up? Hey, what's up? So it's actually a question, since you're working with Verso, and I saw Next.js in the readme, is that, does Next.js has any relation with actual Serverless, or it's something else? That's a great question. Yeah, Next.js is a serverless React. Wait, what? That's so cute, by the way. Yeah, Next.js is a serverless React framework. This is different, in a way, comparable to Remix, because both of them have, like, Remix forces you to have a server, and it's entirely server rendered, but Next doesn't. So you can generate a static site from Next and deploy it to a serverless CDN, content delivery network, where you serve static stuff, or Next will actually server render stuff for you as well, and this is something I'm excited to show you how Vercel will do that. So yeah, Next is definitely, I'm not gonna try to say Clement, I'm sorry. Yes, what's up? You raised your hand, Clement. You're gonna say something, or was that a butt dial? Where's the button? Oh, okay, well, Oscar, what's up? The question that I have is, are you going to do a little bit of the Edge, like Cloudfarer or explain a little bit? Yes, definitely. I love that you mentioned that. Thank you. Thank you very much, yeah. Vercel Edge functions, so good. Awesome. Good, I like this. I love the collaboration already, and I'm really excited for the time we're gonna spend together. I remember going into this, I was a bit nervous. I was like, shit, am I just gonna be talking to a bunch of bots with the camera on? And yeah, but it's fine. Okay, so cool, let me just adjust the readme. Yeah, feel free to put your hand up, unless there's something you want. That's working. Is that Clement? Yes, sorry. Yes, my Mac wasn't working. Just a question, what would be the best use for serverless? Is it like just something where you don't have much traffic? So half of the time it's not used? Yeah, that's a good question. I'm going to answer your question by drawing diagrams. Feel free to watch my screen. So traditionally, right? If you have a site, like a React app, whatever, you usually will have, why is this a dotted line? Okay, you usually have your React app on your computer. So your computer. And what you'll do is you'll want to upload this somewhere so everybody can access it. And how you will do that is using AWS, Vercel, whatever. Let's call it Cloud, the Cloud CDN. A CDN meaning a content delivery network. Its one job is to host static file, HTML, CSS, JavaScript. So on your site, you have a Build step, right? You'll do like NPM Build or something. And you'll get static assets. So then you will get some HTML, CSS, whatever. So this is what happens on your computer. And then by the way, if you used, if you've ever used Vercel ever in your life, this is what they do. So you like Next Build, it just runs this, gets you static assets. You push it to the Cloud CDN, okay? This is a serverless setup. In a serverful setup, you would have to maintain the CDN. And you'd have to maintain complexity like across the world. How is it distributed? So like, if this is the world right here, let's draw the world. So there's North America, South America, Canada, Europe, Australia. Wow, it's amazing. So if this is the world, right? You'll want to have your CDN here. You'll want to have it in multiple places, US East, US West, Australia, Europe, South America, maybe Canada. This is really important. And these are called points of presence or POPs. It's very important to have many POPs because if someone here from the US wants your website, they're going to get it really fast from this point of presence. But if you don't have this point of presence, then they have to go like all the way here to Europe. And this latency is long. It's very slow. Nobody wants to wait that. There's actually empirical evidence that if somebody has to wait more than a certain number of milliseconds, they're going to just like not give you money. So having multiple points of presence is very important in a server cloud network. And if you don't use serverless, you would have to manage this shit yourself. You'd have to literally create servers and put identical configuration on them in multiple parts of the world, and then install like monitoring software to deal with them. And you'd also need to configure something called Regional Failover where if say, for example, somebody tries to talk to this point of presence, but it's not available, like it's broken, then automatically this request would be rerouted to another available point of presence or the root node. So all of this is like complete server bullshit that Vercell and that AWS and that Heroku and that everybody else saves us from. Small question, as far as I understand, content delivery network appear much earlier than cloud, well, serverless and it's totally separate. So we can have, not a serverless but still have a CDN. Yes and no. So serverless by definition is you don't manage servers. So if you're using a CDN, that can be considered serverless because you're using, so for example, Akamai, the most famous CDN, you're using their servers. You don't manage the servers. Therefore it's serverless. Oh, sorry, I didn't erase my hand, but basically if I have all the management done on my server and I expose that for some public offering, expose that as a service, basically from anyone else's point of view, it's a serverless technology still, I guess. Let's use another example than the CDN because that can be confusing because CDNs were around before serverless became successful. So let's say you have a site. Let's call it, why is this green? Sorry, I have a thing with colors. Let's make that white again. So you have a site, this is your site and every site usually needs data, okay. So you decide, hey, I want a database and that's cool, but your site needs a way to interact with the database. So you need an API. I'm not gonna talk about how your site is deployed.

You may self-host, you may use CDN or whatever, but your site will call out to an API. Your API will interface with a database. This is very common. Now your database over time, what's going to happen is you will need to scale it. Say your app gets very successful, very popular. There's two, let's actually change the color here to red. The red things are servers that you maintain in a non-serverless setup. So you will have to maintain an API server. What does an API server look like? If you've ever written express, let's, you know, index.js, right? So you will do something like require express. Oh, I just got to get GitHub Go Pilot. This is so cool. Express and then you'll do const app, right? And this is the most basic API server, app.listen 3000. So this is a server. And in your API, you could do something like app.use slash my endpoint. And you can check for authentication. This is sudo code by the way. And then if it's authenticated, or rather if it's not authenticated, then you can res.status. This is, welcome everybody, this is Zata. I liked Joseph's picture because that's the reaction I hope everybody has on Zata. So in Zata, we have this notion of workspaces, which is kind of like a GitHub Org. And these are databases. So these databases actually runs in the Zata Org. These are actually our production systems that depend on them. For example, this blog database here. And this is important because we're gonna be using this. So it's important to spend at least two minutes showing you around. This blog database, if we go to posts, literally runs our production blog. So if I go to Zata.ios slash blog, all of the content here, this is an XJS app, and it uses as a serverless database, a serverless backend, uses Zata. So these posts are these posts. But you'll notice the order isn't right. This starts with JSConf Budapest, this starts with JAMstack. That's because this is a customized query. So like if we sort by date descending, now it should match. And how we query this in the front end is we click on Get Code Snippet here. And we get a code in a language we like, like JavaScript, copy, paste. And that's our front end. So that's the developer experience we're going for. Also, we kind of make the schema of your database to your tables and stuff quite easy. So like you can see these, we have authors, post and people. And posts depend on authors via that column there. So it's just we try to solve a lot of the database shit so that you can actually build a blog and your websites. And I'm showing you this because it's quite important as you get access and we build a product. So how do we give you access? The allow list is in a database called beta allow. I've hidden the emails. Oh, that's fine. The API key lasts only 10 minutes. Don't worry about it. It says actually here if you read a bit. Below is a temporary access token that will expire after 10 minutes. It's just to make something, getting something really fast. But thank you. I appreciate you looking out. So I've hidden the email addresses because we don't want to leak that. Okay. We have our database piece set up. I think it would be cool if we use a collaborative single database. Awesome. I'm seeing a lot of thumbs up. I'm seeing no problems. This is exactly what I wanted. Isn't that so much easier to work with as a database? I'm not writing fucking SQL. I'm gonna stop here. Small question. It's actually requesting some kind of workspace and I don't see any way to log in or something like that. That's fine. If you're logged in, yeah, you should see create a workspace. A workspace is like a company. It's like a team. So there's a Zata examples team where I will invite you in just a minute. I have your email addresses. So what you're gonna do is you're going to receive an email to join my workspace. I tell them it's a developer experience company. Like we have one job and that is developer experience. Like if you go back to this shit that I drew. We take the developer experience of all of these things and hide them behind rest and give you comfort. So Zata is all about comfort. If you leave here with one thing, that's what I want you to leave here with. We're all in the same org now. So let's create a database. This will be the database for our project. I appreciate your test databases here. Feel free to delete them if you want or leave them. We really don't care. So I'll add one. We'll call it, what should we call it, naming things, let's call it home. So we have the home database. Confirm everybody has the home database. And you're an owner, so you should be able to go into this database and look around. You'll notice I have a feature that you don't have, SDK Playground. We'll talk more about that in just a minute.

But what we want, let's go back to our mission. We want to build Stripe home. And if we go back to our GitHub repot, github.com, instead of github.dev. These are the features we need. Someone needs to be able to sign up or log in, create a user profile, manage teams, and assign a user to a team. That's like table stakes. That's the basic for something like Stripe home. How can we do that from a data modeling perspective? Let's get rid of this. We'll need to create a users table and then a teams table that relates to it. So will someone, whoever, wait, maybe I should pick someone. Otherwise, everyone will try to do it at the same time and it's gonna get fucked up. So Arsalan, can you create a users table and then define a reasonable schema for something like Stripe home? The UI should update if you change visibility automatically. You shouldn't have to reload the page too. To be fair, we've never really tested collaborative features like this. So I don't really know how this is gonna go, but if you make a table in the home, yeah, awesome, I see users. There's an ID column. This is going well. And let's maybe add some columns. So what does a user need? They need a email address, a display name. Now that's good, excellent participation. Thank you. I feel like I'm talking to human beings and not bots. This is so valuable. Okay, so we identified team. Team is really important. That's great. Let's do team at the end, though. How's the table looking? So my UI, oh, awesome. Team is a FK. That means foreign key. Yeah, this is good. So good. So Avatar, let's add one for Avatar URL. Arsalan is in the driver's seat, so I'm just telling you what I see in the chat, okay? Great. So Avatar URL, team is a foreign key. Now, we'll get to that in a minute. Let's have a nickname, why not? Let's have some pronouns. Oh, you used kebab case for the Avatar URL. I dig it. Yeah, instead of gender, let's do pronouns because they matter when you're addressing someone a lot more than gender, although gender is important. Cool. I think we have enough. Name, email, age, avatar URL, nickname, pronouns. This is great. Okay, we have users. Let's now make another table. I'm gonna have Tristan do that. If you're in the same database, Tristan, you can add another table for teams, and teams, I think, are really simple. They just have a name. Maybe they can have an avatar, but that's, I don't know, I have a frontend team. That's really all it is. A description if you want to be extra, as long text, but...

Okay, awesome. Yeah, our real-time live reload's a bit sketch, but I see you adding columns there. I love this. Yeah, defining the data model is really important, because we don't want to fuck this up. It can be expensive to change, but with Zara it's not, and I'll talk about that in just a minute. Teams have a name, awesome, and if you want to add a picture, that's cool, a picture column, which is just a string. If not, that's cool. So now, here, if you watch my screen, here's what I'm gonna do. I will go to users and add, oh, someone already added a team link, wow, look at you, who did that? Was that Julio? Someone? Anyway, cool. So if we go now to the schema view, you can actually visualize your relation, you can highlight on team, and you can actually see, okay, so a user belongs to a team, this is awesome. Let's add some team. I'll just add teams, it's probably faster that way. And we do need to rush a little bit. So, yeah, the real-time is not intended to work always. It's not actually a WebSocket connection. We use under the hood, if you want to learn it, if you're interested, we use React query. And it has its own really cool, like real-time, fake real-time mechanism. So I'd recommend looking into that if you want. So, okay, so let's add some teams. I'm going to invite everyone with access to this teams table to just go add some shit, front end, back end, get creative, doesn't matter. And you can leave the picture blank. Everything's nullable and it's added by default. Okay, let's see. People having trouble inserting? Ah, okay, awesome. At least team orange, front end, best team, DevOps. Cool, that's good. Okay, so what you'll notice is, everything has a unique ID. That's an internal detail, you shouldn't have to worry about that. But you can set ID to whatever you want as well. Just as long as it's unique. So now if we add, let's go to users. We want to sign up, okay? So now we'll start writing React code. I think we've defined enough of a data model to start doing some React work with Zada. Okay, so what we're going to do is, create a sign in page and then store users in Zada. Okay, so we'll open Visual Studio code. And to begin, before doing anything, I need to install, or I don't need to, but it's comfortable for me to install the Zada CLI, which will be like my best friend as I work with it here in my next JS app with data. Arsalan, you asked about TypeScript stuff. This is the answer to that.

So, what I'm gonna do is, I'll put this as well in the chat, but I'm running a curl command to install the Zada CLI. But what I'm about to show you will change. We're going to do npm install global and all of this. This is just private beta stuff so we don't fuck up the npm ecosystem. So, this is how you install the Zada CLI. You'll want to run that in your terminal and you will see something like this. Zada was installed successfully to wherever. If you did that, feel free to do an emoji reaction so I know you succeeded. If you need help, that's what I'm here for.

So, now I have the Zada CLI and I can do things like Zada help. This allows me, everything I did in the web UI, I can do here in the CLI. So, it's a bit more comfortable, okay. To start with, we'll need to do Zada Auth login. It will ask you to introduce your API key. You can get an API key by following me. So, if you go into your Zada UI, if you click on yourself here and go to Account Settings, I have way too many API keys, but you should be able to add one. Let me delete my CLI key. I'll add a key called CLI. This is the key, this is my key, it's fine. I'll revoke it after. What I'm gonna do is copy it here and then paste it in the CLI. And it says, good, you're authenticated. Okay, if you've successfully authenticated the CLI, I would like to know if you do an emoji reaction or write something in the chat. Could even be a, wow, this is awesome, in the chat, that'd be great. Oh look, it's customer data. Okay, nice, great. Oh, certificate expire, what the fuck? Clement, you use Windows? Charles, if you need Windows, let's go here to the docs. And for CLI I believe there's some Windows commands there too let me get that for you. Windows, something with IWR and IEXL pasted here. No, I use Mac. Okay, well somebody was asking about Windows, so. Yeah, Charles, you're having issues, that's interesting. Is anyone else having that issue with SSL circuits? Okay, can you run it again? Sorry, I may be out of ideas if that persists because that would mean then Zara.io would have SSL issues which we don't. So can I access this? Oh shit, you can maybe do that. You can just download the shell file and then run it by dragging it into your terminal. So now you have the CLI. What can we do with the CLI? Was that even important? So yes, it is important. Watch me and follow along. The assumption here is that you've already authorized Zara. So now here's what you're gonna do. You're going to do Zara in it, in the root of this. And it'll ask you, choose a workspace. So I'm going to choose Zara learning. Can somebody please share the GitHub link? I can share the GitHub link to the workshop. It is this one, okay. So now it asks you to what database do you want to pull from and you can create a new one or you can choose one. So we're going to use the one I just made, which is called Home I believe. Yeah, Home. Do you want to install? Look, Arsalan, this is your moment here. Do you want to install the TypeScript SDK and code generator? The answer is yes. And now it will install stuff in our node package that will allow us to comfortably query Zata, okay. So far so good. What the fuck. Okay, so you have, look at this, you have a hyphen in your key because your column names are a bit mangled. So we're going to have to go fix that. To be fair, I've never, I haven't really, that's a good test. So you have avatar dash URL. That's a problem. So let's go fix that and make it camel case or underscore or whatever. Rename the column to avatar. Let's use camel case. Okay, we'll run that again. So Zata init, the directory Zata exists already. So this, if you do LS here, it introduces a folder into your project. We'll remove that folder and we'll run Zata init again. If you're not able to follow along, interrupt chat, this is what I'm here for. So now again, which workspace, which company, which team? Zata learning, which database, it's home. Do I want to install the TypeScript SDK? The answer is yes. And now it's doing its thing and we are ready. So what just happened? If I do LS, it's done some work. It's created a Zata directory for me and it's created an SRC directory for me or it's put something in my SRC directory. Let's look at the Zata directory first. So we'll actually let's do this in Visual Studio Code. So Zata, it created a schema.JSON and a config.JSON. The schema.JSON is actually my database represented as code. So if I fold this, what I can see is tables. I have two tables, users and teams like we made them. This is nothing new. We just pulled it down and some configuration, like this is the database name, this is the workspace ID and so on. You won't ever touch this. This is just for internal stuff. And also there's a zata.ts file. And these are fully type safe things, which is quite exciting. What can we do with this? We can actually query Zata in a really type safe way. This is what I wanted to show you. So this is our project, we're done with the setup anyway. So now if I want to query my list of teams from Zata, how can I query it? Make a new file. Exec what? Clement? Are both of you on Windows? Ah, this is a Windows thing. Okay. I don't know how to fix it.

And you probably, it's not going to block you from using Zata, it's just going to block your code generation piece. Yeah, yeah. Exactly. So let me give you the TS file. Sorry, we'll fix the Windows Code Gen. But let me give it to you for now. So paste bin. And I'll keep giving you this as we go. So here's your TS file. You want to put that in your src slash zata.ts, okay? Cool.

So what can we do now that everything's set up? If we go to Source, we make a new file, pages slash API slash teams dot TS. This is a Next.js API route. It is a serverless function. It's the same as Cloudflare Workers. You may have heard of it. It's a function that runs in a serverless function provider like AWS Lambda, Cloudflare Workers, et cetera. So we'll say handler or let's call it function. Is function a reserved word? It is. Okay, handler. It's a Next.api handler. It's an async function which gets a request and a response. We'll make that the default export. And in this function, we can query Zadda. How do we query Zadda? We need a Zadda client. So we'll do client equals new ZaddaClient. As you see, it's not here because we need to import it. So we'll import this from...Zadda. What's the export? ZaddaClient. Okay? And it's all TypeScript. So as you can see, I'm autocompleting. I'm tabbing around. This is the TypeScript way. So now I can instantiate that new ZaddaClient with no arguments. And now I can query... Look, it's pages slash API slash teams. So I'm going to query the teams. So I'll do const data and I'll await client... Wow! I didn't... I just got copilot today. I was not ready for this. Client... This is actually wrong, but Client.db... And I have this from Zadda. These are my tables. So this is quite cool that I can just do this. There's a TypeError in... Is there? Where? This is good to know. I might take a screenshot of this for later. Expected zero to two arguments, but got three. Where in the world is three arguments? This is clearly two arguments. Fuck. If anyone can tell me why this says three arg... Ah, arguments to super. Got you. Yeah, this is, I don't know. Let's see if it works. Teams.getAll. This type safe way from Codegen is how we interact with the table we just made. So we've made some teams I imagine, right? Let's take a look. Teams. Yeah, we have some teams here. So we'll query this. We'll say res.endData. I expect it to say records. Ah, maybe not. Yeah, it's type safe. Okay, so data is just going to be an array. Let's see what happens. We have this. Let's run our server. So it's eight pages. So it's API slash teams is where we want. API slash teams. 404. Okay. How are you 404? I just made you. What? Okay. Am I? I'm just gonna make a reactive port and see what happens. I think like some good debugging comp. Okay, let's try this. Yeah, so everything's 404, which tells me my next.js is not actually. Oh, right, I have to be an SRC. Ah, I was not an SRC, perfect. So now I should have, okay, it's working. So API slash teams, options, database URL and API key are required. Okay, that's fine. We should have them here, here. But actually they are in here, I think. They are in config. Okay, so database URL.

Okay, let's get, so we need two options. One is database URL, let's, database, wait. Yeah, URL and API key. Both of these we can get from the web UI. So if I go here, start learning, so if you go to configuration, you'll have your database URL. This is your database URL. This is dedicated just for your database. So this is your workspace ID, database name and database branch. We will get to that. Yes, Zada is like a Git repo and you can actually branch your database to add features. So we'll start with this. Our database is called home. If someone's TV is being played, appreciate if you could mute it. And this is the main database branch. And the API key is the one that we generated. Actually, it's not because we generated a CLI key. Let's do another one just for our app. So we'll call it home app. This one we'll store in a.env file. So.env zada-api-key is this and we'll read it here. Zada API key is, I could just do a string, but it's not actually very safe. Why are you complaining? Client. What is wrong with you? I think it's maybe just my TypeScript thing. My TS config had some issues. Module resolution has to be node. It's weird that they generate something else. Save. Hey, are you fine? Yes, everything is fine. It's database URL, I love TypeScript, perfect. Okay, we're good. Let's restart the server to get the.env, and it says here, loaded.env. Right, that's important. So now let's go back and fetch branch name, invalid identifier. I think we actually infer the branch name. Forgive me, and here. Okay, perfect. So we're getting data, but we can't send data over the HTTP network. We have to stringify it, there we go. So we were fetching, what the fuck is this? So we're fetching this directly from Zara using a nice type-safe client. So like if I don't have a table called, nice one, Nada. If I don't have a table called Teams, I'm going to have a bad time, or at least I should if the type generation worked. Wait, dot, yeah, teams dot get all. Next, this is way too nice. I don't really know why it does that. But what we can also do is filter here, so I can filter for my specific team. Actually, let's use query params for that. So we'll add a query param, filter, rec dot query. And we can do that. So we'll filter where the name starts with, or contains, name contains filter. What do you want? We'll tell TypeScript this is a string. Okay, so now we should get every team, if we... Or no team, sure. Let's maybe get rid of this. So our filters are a bit exclusive, I like it. Okay, so now let's just filter for Ali. So we'll do, filter equals Ali. Yeah, so we have something cool like this. But I kind of want to... So what we'll do is two types of data, right? We'll see if there is a filter, then filter. Otherwise, we just get all, this is nicer. We can remove the filter. What I wanted to show you the filtering thing is the column names are strongly typed. So if I do something like this, it's going to be like, you don't have a column called Naksmi. What the fuck? Okay, anyway, so it looks good. So far, we're able to get a list of teams. Let's write some React. Because now I'm going to commit and push this, by the way, just so you can pull this and have the code. Let's recap. These are automatically generated from Zata. This was automatically generated from Next.js. We created this route. We can delete this one. This was automatically generated. This was automatically. So it's just a bunch of automatically generated stuff. I'm just pushing to main, I hope this is okay. Should I push to main? Yeah, it's fine. Add auto-generated files. I'll add everything except the teams route. And now I'll add the teams route in a separate commit. Okay, I'll push that. You should be able to pull that to just be where we are. Cool. So now that we get a list of teams, step one, which we have only one hour left, but the goal is learning. It's not really finishing the project. I'm glad we have enough. Again, feel free to interrupt me with questions, with comments, with you know, whatever, chat. So sign up and log in. We have a list of teams. Manage teams is a bit further down, but now that we have a list of teams, we can maybe create a signup form and ask a user for a team.

Okay. How are we going to do that? We might skip the tailwind piece, by the way, for the sake of time. And we'll just use an ugly-ass UI. So let's start with a signup. So we'll do pages. We'll do signup.tsx. This is a React component that is about to interact with Zada. So classic, classic React. We'll do a form with a label for your name. What is our, what is our, I need to remember the schema of our table. I could look at the code too, but I kind of want to look at it here. Okay, so name, email age. So for signup, what should we ask for? That's a good question. You can ask for all of it. It'll be quick. Input type for this text.

Does anyone have VSCode live share? If you are, you can come write code with me here. I'll send you an invite in just a minute. Then we can parallelize stuff.

Okay. Copy again, what? Okay. If you're doing the project, you're welcome to create this form with me. Otherwise it might be a bit boring. So I'll do columns and I won't mess with you. Name is required of course. Okay. Should add. Yeah, thank you. That's exactly what I was going to do. So we have name, email, age, avatar URL, nickname, pronouns, team. Email, this will not take too long, I don't think. Yes. Ali, welcome. Feel free to adjust columns here. Okay, nickname, pronouns, and what was the last one? Team. Okay, age is a number, photo of you is a file. Nickname is text, pronouns is text, and team is a select. Who wants to? Someone, not have, you can replace that with a select with some options. Why not? You don't have read, write, what? That's bullshit. You're totally not read-only, man. Look, it says on my screen read, write. Read, write, so is Ali. Julio, are you... This is awesome, see? So good. Nice. We can do some hard-coded ones. But the goal is to fetch the teams from Zara and populate them here. This is awesome, except read, write. Chanimo from Windows, he has Windows, that's gonna be the best. Okay, while somebody's making the options, I want somebody to write a use effect that fetches the teams from our new API endpoint. So yeah, if you add a use effect and then a use state to store the teams, that'll be super helpful. Yeah, somebody wants to add a use state with teams just above the use effect, that'd be cool. Perfect. You're doing great. This is good, this is exactly how I write React apps with A. What is the name of the module? This is good, this is a good question. Okay, so why am I following Julio? Like, can I stop? Oh, shit. Sorry, Julio, I accidentally removed you. Maybe join again, it was an accident. I thought I would stop following you. Instead, I just like canceled you. Cancel culture, that's a bit fucked up. Okay, so cancel culture is not fucked up. In fact, I canceled you is fucked up. Anyway, so yes, oh thanks, Mr. Organi. Okay, so here's what we're gonna do. So we need state first of all, to hold the teams. Teams, set teams. And we will use state. It's an empty array to begin with, but it's going to be an array of teams. So we need to define a type. Why the fuck are there two separate imports? Okay, we need a type for our teams. Our teams have an ID and a name. Why not use the, what? Oh, that's so smart. That's so smart, shit. This guy's a genius. Import the type from Zara. So good, there's a team. Wow. What is team? Name and picture? Hey, that's not right. Actually, it is, but it also has an ID. So we'll do team. I don't know why the type gen doesn't include that, but it's team and an ID. Okay, cool. So now fetch teams async exactly. What's gonna happen? We need to fetch from api slash teams. See, we made this function right? And we're gonna get back json. And then we're going to set teams. That's it, that's all we're gonna do. We actually don't need any of this. By the way, you cannot contact API of a hatta from self client side. You can, but you shouldn't. Can you tell me why? Probably exposing your private key, which is public key. Your API key, yeah, exactly. If you query zada from here, what's going to happen is you can inspect the DevTools in the network, look at the authorization header and you're fucked. We will allow you to do read only keys, but generally like you don't want to include secure stuff, client side. It's just a hostile environment, but with Next.js this is easy. We have this. Also, you're the first in the world to hear about it. We're actually working on a use zada hook that you can do from the client side. But then when you run npm run build, what's going to happen is we take the use zada hook, we deploy CloudFlare worker that fetches from zada and your app doesn't fetch zada from the client side. It just fetches some serverless function that we create at build time, okay? This is awesome. Whoever was writing this, Nadev or Julio, I think. Thanks for coming back, by the way. Team is an object.

So you want to do team.id. And then we'll do, yeah, you can fill in that. So team.name, I guess, right? Team.name, awesome. This looks great. Todo use React Query, I love it. Save. This theoretically looks like it's going to work. If you want, look at my screen right now because I'm going to run it, or it's already running. What is it? Sign up, right? Sign up. Someone fix this. And then I think if you save, my page should just live reload. Fuck, that's so cool. Wow! This is the coolest thing I've ever seen in my life. I'm not touching my computer. Unexpected end of file. Did you forget the name? Sign up, export default, sign up. I'm not touching, this is so cool. What happened here in the chat? Visual Studio live share, live share, this one. Why is this not? I guess it partially saved. It's a bit fucked up. Okay, cool, it works. That is the ugliest form I've ever seen in my fucking life. We need, I can't. We maybe won't use Tailwind, but I need CSS. This is, I can't function otherwise. We'll use CSS, we'll just do SRC main.CSS, something like this. TSX and then Next.js has some type of like underscore app global thing. This is not part of the workshop, I just can't work with something so ugly, pardon me. Paste, and we'll just import the CSS here. There we go. Yeah. Okay, I have to, sorry about that interruption. It's just really important. And then we'll export default. Wow, somebody did that already, thank you. Okay, we have CSS, thank God. Form, display grid. So much better. Okay, that's awesome. And then label too, right? We want label to be a flexbox. Display flex, gap, I don't know, eight pixels. Oh, that's, man, so much better. Our form is missing a Submit button. Can someone add this, please? Why? Something in the chat? Okay, I fixed nextjs for the win. Amazing UI, it is the most amazing UI. Thanks, Julio, this is super helpful. Okay, nice, call it sign up instead. Cool, we have a nice form. It's a bit ugly. Let's maybe, you know, max width, 640px, margin zero, or 64px, auto, ah, so much better. Now, I'm just really freestyling. Alright, okay, board, last thing, promise. Oh, thank God. Okay, yeah, Dave, am I? I don't see a request for you to join the live share. By the way, if you wanna change the CSS or anything in real time, feel free. Not a problem, but just maybe don't fuck up the syntax. Yeah, I'll let you get really creative. But keep in mind, we're building an app here, okay, so let's maybe not get too crazy. Wow, Sofia. I don't even know this font. Who asked for the live share? Dave, you, I haven't seen a request from you, but if you want the link here. Okay, does it look good? It's fine for now. What the fuck is the signup button? Why would, okay, anyway, it looks fine. Can, let's get back to it. What I want you to notice is Ali's team, we have the teams from Zara, if you look at this fucked up pixel, like flash, do you see that? That's fucking disgusting, I hate it. We're about to talk about, so let's recap a bit what we've done. We have... Oh, you're trying to fix the flash. Okay, I'll let you do. This is actually important for the workshop. Okay, nice, nice try. So now if I reload... Actually I can't fault that, but I can. I get a flash sometimes. Like, if I reload here, there's a flicker and it's not really friendly. So yes, that's cool. But okay, wait, wait, I have another option. Let's view the source code and search for Ali's team. And I don't get it because that shit doesn't come to me statically. So nice try, but no. We're about to... So let's just recap and then talk about a really important strategy for working with serverless apps. What have we done so far? We've created a database. We have queried it. We've got access to it. And we've done a lot from the database side. From the serverless side. We've actually created a serverless function here with the Zada Client. And we're actually querying a database. So we have an API.

Going back to that diagram here, we have an API already handled for us. So this api-server thing. When we deploy this, our thing that fetches data from Zada is going to be deployed to next to Vercel's serverless functions runtime. Our database, the Redis, the Kafka, the search, all of this comes from Zada. So let me just delineate with colors a bit. The green is Vercel. The red is Zada. And we have all of it already. So this workshop has been really heavy on the serverless side, introducing you to Zada and Next.js and Vercel, if you haven't already. But let's also maybe deploy this. We'll do Vercel. We'll actually deploy it just for fun. Yes. I don't know if you hear the siren. I apologize. We'll deploy it to my team. Do I want to link it to an existing project? No. My project name is serverlessworkshop. The code is here. Now, kind of like the Zada CLI, Vercel CLI is very similar. Every serverless tool will do something like this. These settings look good, and so now it's deploying, our thing. If all went well, it'll just work, but it's probably not going to work because we haven't set environment variables in the Cloud. Exactly. Now, good catch. So let's do that. Then we'll have a fully serverless setup. But I wonder, what? Interesting. Probably the build failed because we don't have the secrets set up, you can go look. If we go to functions, the deployment failed with nothing. Let's go to the log. It's this type error. Cool. Let's just go fix that. So you're telling me you don't want that? Okay. Cool. Or maybe let's just opt out. I'm not sure if that's needed or not. Let's deploy this again to production, straightaway. What we're doing now is we're deploying a React app to a serverless setup. The static site lives on Vercel CDN. The functions are executed on AWS Lambda, which Vercel uses under the hood. Sure, yeah. No problem, Arsalan. And the database, of course, lives in Zada. Okay, so those are our three different serverless things that we're stitching together. And after this we look at, and this is really important for you and your work, I think we're gonna look at fetching data responsibly with React. So that means no flash content. No if, no teams, then null. Like, we'll fetch data in a way that is nice user experience. So the build succeeded, it deployed. This is fine. If we go to sign up, we should have our form. Okay, and it actually does fetch from Zada. Holy fuck, I don't even know how that, it's probably talking to local host. And that, let's confirm, slash teams, where is the? Oh wow, damn! That's like next level from Vercel. Environment variables, just up to the cloud. This is the first time I see that, holy shit. Okay, so it's working. Even deployed here, you can have the link if you want. You made this collaboratively, congratulations. And what this is doing is we're stitching the Zada API along with Next serverless functions and the CDN together. But the problem is especially you will see this more now that it's deployed to the network, if we throttle our network to something like slow 3G and reload this, we're going to have a really bad time. Because the page loads, but then it's empty. Look at this shit, it's empty for a while. Just because I'm waiting for teams, and now when I get teams, something shows up. This is not ideal. How can we fix this? We can fix this with to serverless rendering approaches in React. I apologize, if I'm moving a bit fast, it's just we have a lot of ground to cover. And so I do want you to learn these things because it's really important for serverless. Now, when you're building apps in React that stitch together serverless providers, there's a high chance you're going to be doing a lot of network IO, you're going to be doing a lot of requests from different providers, okay? Kind of like to get teams, this is one example, there's a good chance you'll be getting data all the time. We look at how you can get data in the best way. So this I don't like because there's just a white screen of something loading. And this is shit. So let's fix that in localhost. We'll do that using server-side rendering. Server-side rendering is quite cool because if you watch my screen again or follow the live code, instead of using some extra API route like this for teams, we can co-locate the code in our React component itself. So any page in pages allows us to export another function called getServerSideProps. And its type is also getServerSideProps. It's an async function that allows us to... Wow, Copilot is nuts. That allows us to do stuff on the server side and then give it as props to the client side. So what we're actually gonna do is this API route, we don't actually need this to be an API route. We can come here to our signup page and we'll just paste the code here and we'll take this body from the handler and just put it inside getServerSideProps. I got you, Dave. So now our getServerSideProps can get some stuff, but we don't have a rec, except we do, it's an argument. Rec, I think query maybe its own argument. Yeah, query. Okay, thanks. We can actually just get rid of that.

And now instead of res.end we need to give it as props to our component. But if we scroll up, what type of props does our component expect? Let's define that. What props do we have? We have teams, it's basically this type here. So that, we don't need state anymore because props are coming from the server-side. We don't need this whole shit. Look, oof, it becomes a lot simple, oh shit we do need handle submit, do we? Okay, maybe later. But we don't need all of this like convoluted lazy loading, whatever. Teams are still there, but they come from props. So now this is a function component that has props and the props are teams. So now, we can also tell it we want these props. We can tell getServerSide props to expect those props. And then when we return, we'll return that our props are, that our props are teams. Teams is data. Okay, this looks good. Was everybody able to follow that? If not, there's a chat, I'm here. Cool. Why, this is wrong, it's just dot dot slash. Perfect. We can remove state and effects and save. We can also delete this API route completely. We don't need it. It becomes a lot simpler.

Okay. And now let's go back here, reload. I killed local hosts, so we'll start local host again. And now, so this comes from the server and it's fucking instant, it's server ended. And the benefit of this is it's even better for SEO and things because Ali's team is now part of the generated HTML markup. Like I can like, look, it's all there so it's ready to use immediately. This is a very important, someone fucked up the select. You did a map without a key? You should be ashamed. Hey, this is not a basic React workshop, okay. There's an ID. Come on. Whoever did that, fix it. So, what did we just do? Did we make things faster? Arguably, but not really. Oh, someone fixed it. Thank you. We, oh, okay. Things are happening here. Maybe that is Julio. That's awesome. Thank you Julio. Perfect, good. So, here's the question. We moved from client-side rendering to server-side rendering, okay. Did we make things faster? Who can tell me the answer to this? If you wanna unmute your mic, yes or no. Nope, nope, nobody knows. What was that? Kind of, because now everything happens like on strong servers. Not on the browser, but not much. Yeah, exactly. In many cases, a lot of teams think that server-side rendering is going to make your app faster. It doesn't. You move the spinner from the browser to your server. If your server is in a network with faster internet, then that round trip to Zara is going to be faster, but effectively you're just moving spinners and in some cases, the browser is actually faster because you can use HTTP caching. Okay, that's a really good answer. But actually when we have epic calls from the server side, usually we have our API on the server side and the same infrastructure as well. So we actually benefiting from cutting latencies of these requests. Yes, in a traditional way, yes, but in serverless, by definition you don't have your servers in the same network, right? So yes, I hear that. There's one thing to be aware of when doing this kind of work with serverless, the server's outside of your, it's called the VPC or your Virtual Private Cloud. And so you will have to consider that as well. Okay, so far so good. Let's deploy this now to production Vercell dash dash prod and I will, wow, look how collaborative. We will commit these changes and push them so you can pull them. I like that we're making really good progress here. Hey, thank you everybody, by the way, for your participation. This is a lot of fun. Okay, so let's say now fetch teams with SSR. Boom, push, how's our deploy going? Okay, deployed to production again, let's go check. Now when we reload, even on slow 3G, we're not going to end up in this weird blank screen that's fetching because the fetching happens on the server. So when we load it, it's immediately Ali's team here. We're ready, again, it's a hard reload. And so there's something to be said here because I asked you if it made things faster. The answer is kind of, probably not, but also kind of, probably yes, because in perceived UX, that is what the user sees, they see things that are actionable immediately. And that's very important. Let's take a look at some latency numbers here. How long is this taking to load? What we can see is, from start to finish, seven, what? 7.9 minutes is bullshit, let's reload this. How long is this taking? From start to finish, 5.83 seconds on slow 3G. Yeah. That's finished with the network requests, and the full page load is 5.88 seconds with the server-side rendering. Keep in mind, when you work in a serverless environment, you will always have to fetch like this and make decisions in your React apps about how you fetch. This is okay. I think six seconds is a bit slow. What other loading strategy can we use with serverless React and should we use? So, to recap, client-side rendering is great, but it's probably slower because you're at the mercy of your user's network, and also slower because you load an empty thing first and then there's a spinner. It's not as good for search engine optimization because you essentially have a skeleton that search engines are seeing. So, because of that, we switched to server-side rendering. It's called server-side rendering, but we're doing it in a serverless way because we're deploying it to Vercel's serverless platform, as we can see here. And the benefit of that is the spinner is moved to the server. So, Vercel's server, not our server, it's still serverless. The fetch is happening on their side, and it's probably faster cause their network is built for speed. Also, I'm pretty sure Zata and Vercel are on the same network, that's probably why it's instant.

And so, what's the benefit? It's faster, and also it's faster in perceived UX, and the content is more search engine marketable. You can view source and you have more words. It's not just some skeleton, great. Can we do better? Can we do better than the 5.88 seconds? The answer for this kind of content is yes. Instead of server rendering, we can still build React serverless apps using static renderings. This is what Gatsby does. This is something that Remix doesn't give you at all, and to do this statically, it's a very small change. Instead of getServerSideProps, we change it to getStaticProps, and just by the fact of this function being exported, Next.js knows to generate a static site instead of a serverless function. By the way, what we deployed to Vercel is literally a serverless function. It's an express app that res.html markup here, okay? But I guess, can we still make a call and fetch before generation? Yes. I think there's another function that has like hydration, right? No, it's all in here. getStaticProps is something that will make a network request to Zada in this case, get a list of teams. When the network request finishes, then it will pass the props to the component and continue building the site. So does it unbuild, right? So if I add after that, like a team, it won't be there until my next deploy. So let's do this first. So we already, because we're not on the server side anymore, we don't have access to query params. Therefore we cannot filter. This is one of the trade-offs of static versus server side. Also cookies, anything from the query string or cookies or headers, you don't get anymore. So we cannot filter. It's probably for the best, it gets a bit more simple. And now, save. Let's check what the, I don't want to run that. So let's go back here. Which local host was it? Sign up. Okay. Let's yarn next dev. And so what's gonna change here? Literally nothing. From a local development experience, nothing changes. In fact, we can test this. Someone's trying cross-site scripting, I see you. Nice try, but no. So let's go back and, because React doesn't allow, you have to do dangerously set HTML for that. Anyway. So let's try it. You can, you have Live Share control. You can actually change the code to use dangerously set HTML. So what I'm gonna do is I'm gonna add a record. Cheese. And now if I go back to my app here on local host, when I reload the page, even though it's static site, it's statically rebuilds it. Or at least it should. Have I saved something stale? Something cached, something? Yeah, cheese. So I didn't restart my dev server. I didn't rebuild the site. It's just when you reload, every time I hit the reload button, next JS makes a call to Zara and gives me a static HTML page locally. It's like it's running the components again and again, whenever you refresh it. Yes. So it runs the function again. Someone fucked up the select again, really? I thought we fixed that. Why? Why would you do that? Did someone undo the fix? Anyway, I fixed it for you. I'm glad because somebody learned something in this workshop to put keys everywhere. They learned it by shame. I'm joking, I don't judge you. I also forget keys sometimes. Okay, so good. So far, so good. That's how it works locally. Let's deploy this now to Vercel and see what happens. In fact, what's gonna be interesting here is to watch the build logs. So if we inspect the build, this is quite cool. So if I go here, that's building, we'll actually see it make a request to Zata and then generate static files. Were you gonna say something, Charles? No? Okay. I guess this would be the fastest. You guessed this? Yeah, so it was six seconds I remember the last time. Let's see. Oh, do I have that open somewhere? This one. Yeah, so the DevTool's here. I'm gonna keep this open. I'll do a test in the new tab. So let's see what happened. So you notice slash signup used SSG, static site generation. It's HTML plus JSON. And so when you call Zata and get static props, what it's actually doing is it gets the props as JSON and stores it in the final mock-up. So we're here. Let's visit the deployed site and it's slash signup. This is a static HTML now. It's just fast. Like, fuck. You don't even... Yeah, let's quickly test it here in the network just to confirm. It's a hard reload. Yeah, 2.14 seconds, oh, shit. Okay, so it's actually not... It's like 0.02 seconds faster. Let's try again. This time maybe when it's cached. It's more or less the same. This is really interesting. You have disabled cache active. That's probably why.

Let's do that here. Fine, I'm... Yeah, 2.18. Exactly, 2.18 seconds. So it's a third of the speed. I think that if you undisabled cache on the other one, it will be the same. Well, now it's a bit hard... Let's go back to that default. It's the browser cache. It receives the same, right? Yeah, yeah, you're right. Am I on... Okay, so I'm on slow 3G in both two. Let's just not throttle the connection and see what happens there. So here, here. Okay, it's about 20 milliseconds or 10, 16 milliseconds, so to speak. Yeah, not really that important, but I think as you add more, it'll get any compounded because the complexity is more. But what's the trade-off here? It is, the other thing is, this would be, this demo, this whatever we're doing here would actually be way faster or way more meaningful if we all were not in Europe. In fact, if there's someone here in New York, that'd be awesome because so... I would be really interested in hearing your story because actually can you do that if you're comfortable? Maybe not. But now the source is the same. When you try to compare tabs. Yeah, the source is exactly the same. But, why, who's here from the Middle East? Can you say your name? Yeah, it's me Nadav. Can you say it again? Nadav, like you said, Nadav. Nadav, yeah, yeah. Nadav, yeah. So Nadav, in the Middle East you're going to have way more of a hard time accessing the serverless functions. So the server-side rendered one compared to the static one. And then- Oh, you can try it. Could you share the link? Yeah, let's do it. I think this is server-rendered. So I will send you this one. Boop, boop, boop. SSR is this, and the static one is this. So my hypothesis, just by the serverless approach, is that the server-rendered one will be a bit slower, probably not in a big way, because at the end of the day, it's a simple page, but still noticeably slower, because- Oh, we do have nice internet here. Yeah, online, but oh. Yeah, it's not about... I know, I grew up in the Middle East, by the way, in Catali. But the issue is, with SSR, this is important for serverless, this is important for you to know. Because it's serverless, you think, okay, cool, it's server-rendered, and that's someone else's problem, I'm done. Yes, it's true, but also, it helps you to know where the server is. If you use server side rendering in the Next.js app deployed to VRSL, your server-rendered app is going to be served from US East, always. So the further away you are from US East, the slower it's going to be. And there's no way around it. So if you're in Australia, you're a bit fucked. The serverless function, exactly. So the SSG is about a quarter of the time, maybe even less. The SSG is like 75 milliseconds. Yeah, same here. And the SSR is 352 milliseconds. Fuck! Did you hear that? So this is where, again, you wanted recipes, you wanted ideas for fetching in a serverless way. Serverless, you would intersect with serverless by having to know where the server is. So hey, can you write the numbers? Oh, wait, I'm sorry. I misread you. You've not disabled cache before. So let's just see. That's fine. Can you write the numbers in the chat? Sure. Thanks. So here's what's happening. For the server rendered one, if you're in the Middle East, if you're in Australia, you have to make a request all the way to New York or US East, wherever the data center is. For the SSG one, you're going to have to make a request to your nearest CDN node, your nearest point of presence. So by design, SSG is all of, that's over 100 milliseconds different in a DAV. Holy shit. And over 300 milliseconds in the other case, like, yeah. SSG is always faster than SSR because CDNs are globally distributed and serverless functions runtimes are not. This is being changed. So Vercel has a new offering called Edge Functions. Cloudflare has, they have workers that is globally distributed. So this is not, this is a decision you're going to have to make when you work with react apps and serverless is where is the server and is it globally distributed? Okay. That's really important for you to know. I mean, looking at these numbers, I'm gonna take a picture of this, this is actually really important, but here's the cool thing, Vercel's serverless function runtime, so where your SSR happens and Zadah are in very close regions. So Nadav, for example, you coming from the Middle East, what your app is essentially doing is you're talking to Vercel, Vercel is calling Zadah and then your page is coming back to you. The call from Vercel to Zadah is fast because Zadah and Vercel are close. You get that? There's a plan next year to globally distribute Zadah as well. So no matter from where you call it will be fast. Good. So this is something you're going to have to think about when you're building React apps with serverless because now let's say we add authentication with a service like Auth0, we'd have to actually choose which Auth0 host do we use. An Auth0 would be even more complicated because of GDPR. Where do we store email addresses? If you have customers in Europe, your server has to be in Europe. Their server rather has to be in Europe. And so people from geographic distances will be out of luck. So this has been good so far. Let's continue. So now this is deployed as a static site. Let's go add another team. Let's call it Nadav in honor of the Middle East. But aren't we a little restricted on SSD I guess? Yeah, tell me more, why? Yeah, like just you removed the security patterns. Yeah, we are. But we don't need query programs in this case.

But yes, you don't have access to query programs, you don't have access to cookies, you don't have access to HTTP headers if you do SSG. So we're very limited. So it's trade-offs. You get speed but you don't get like cookies and headers.

And then we're just like what about a static blogs, right? The site that doesn't change this. You would think, yeah, you're leading to the next section. Let me answer this in a long way by showing you some shit.

So now I'm adding a team. I created nadav's team. I go to my server rendered thing, I reload, I don't see it. I could reload 100,000 times, I'm never going to see it because it's a static site, like it's just HTML. It has no way of knowing like, hey, there's new data. And this is kind of what you were saying, like, so SSG is great for like static blogs and stuff. But it kind of fucks up when data changes. If you know the answer to fix this and get the performance benefits of SSG, put it in the chat. It's like, yeah, why didn't it say yes? And if you don't know the answer, why do you wanna put it in there? I feel like that's just an answer that I need to know. That's an answer that I wanna know.

Wait, let's see what happens when I go to the next slide. It turns out I have a run time loop. So that kills all my data. So I'm gonna say how do I build to a server. Yeah, so you can see there's a new loop there, like for data check, and usage changes, and I keep running the ISR. Can you just rename it again, the edge function. Yeah, yeah, we'll come to that. Someone, if your mic is not intended to be on, you might be using that. Julio, do you feel comfortable turning this into an ISR page or should I do it? Yeah, I actually don't remember. That's fine, here, this is how we do it. We still use getstaticprops, but we add one thing, which is we go here, thanks to TypeScript, revalidate, true. That's it, that's now, it's officially ISR. If we deploy this, it'll take like a few seconds. But now what's going to happen is every time you visit the page, it will run this function. It will make a request, it will get new props, it will rebuild the page in the background. And the next person who accesses the page will get the latest data. It uses a mechanism called here, let me show you, web.dev stale while revalidates, it was inspired by this. If you haven't- Does it have like a timeout? If you set it to true, the timeout is immediately, but you could do like- Three hundred milliseconds if you want to. I do true, I mean. You know. That's actually 300 seconds. Milliseconds. You can't tell it to refresh every 300, is it seconds or minutes? It's seconds, milliseconds doesn't make sense. Yeah, you're right. It was inspired by this stale while revalidate, which in itself is a great caching mechanism. How it works is if there's an acceptable stale response, you get that immediately. Meanwhile, the browser fires a request for more information in the background. This applied to serverless is what is called ISR. So it's been deployed and now the site rebuilt. So we should have an AWS team. Awesome. But it's a static site. So let's add another one. Let's do a Guillermo, if I can type. So now what's going to happen is I reload the page like this. We don't have it now. Because what happened was we sent a request to Zata. The page loaded. We sent a request to Zata. We're getting the stuff, it's rebuilding. And if we reload, if somebody comes now again to the site, then they get the latest data and we have shit. That was not supposed to... We should have Guillermo at some point if it actually deployed, which it looked like it did. Yeah. Maybe it's just taking a while. We can actually go inspect. Let's see what's happening here. So the production deployment has functions. Sign up. Let's go request it. Nice. Literally nothing is happening. By the way, this is why it was slow for you because this function is being called from Washington, DC. So if you're in the Middle East, you're a bit fucked. Okay, so what's going on? Why do I not see? That's not going the way I want it to. I don't know. Does anyone have any idea? Try Cognito. Sorry, what? Did you add Guillermo, or did you just write his name? No, I added it right here. Oh, all right. It should be under, let's actually, let's go to local host and try that. I'm not going to rebuild the site. That I know for sure. I'm sure there's just some network requests taking a while. We go to local host. Try Cognito. Yeah. Maybe it's cached. I don't think, maybe it's related. No? Same thing? Maybe site P? No, no, no, it can't be. Maybe we can just change the revalidate to one. But this is really unusual. Also for me I don't see Guillermo Tagliati. Not a problem.

We'll rebuild the site and then we'll add another one. But revalidate one should give us the, unless we're caching things in the Zara client, which we might be doing but generally that's unexpected. By the way, this is actually how we build our docs. So the docs are fully ISR. And some of it, so all of this stuff comes from GitHub directly, we don't even write this. Which means it's always up to date with the code usually, it's quite cool.

Okay, so the site should be rebuilding and we should see Guillermo, because it's rebuilding. Yeah, we do. But let's test the ISR and add another one. I totally added this. I want SSR to do SSR's things or ISR. Yeah, this is interesting. I have no idea what's happening. I think maybe, let's not use- I don't see the true thingy. I mean, I look at the docs and they don't specify the true. Yeah, I just redeployed with one. But I think it might be just to rule out the Zadar SDK, let's do this and copy the code snippet from the browser itself. Instead of console logging the result, we'll just const- I think it's records equals. So, await, right? I think let's just try this snippet here in the browser to see if it works. And we're using a temporary API key. I just want to like rule up the, the, how do you say, the Zadar client could be that. It's still beta. Okay, so we have meta, we have records and records is our teams. So, it's, yeah, this looks good. Does local host work? Do your next dev. Am I even instantiating the Zadar client? I don't need this. Okay. So, yeah, it's working. I'm fetching. Everything's good. So, we'll deploy this now just to see what happens. Cause fetch, I mean, fetch should just fetch. We're not doing anything. We're not doing any caching. This looks exactly like what you want. So, our new site here, we'll have, oops, sorry about that. We'll have Khaled, and then we'll test ISR. Am I using the right URL? That's a good one. Hey, David, thanks for having you here, man. I hope you enjoyed the workshop. Okay, so at this point we have Khaled, it's perfect. Let's add Gabe. So, if we refresh, it builds in the background. We refresh again. Yeah, now we have Gabe. So, okay, so there's not a client that's fucking it up, but ISR does work. It's just our SDK caches things, I guess. Cool, I hope that clarifies it up.

Okay, so we have this, and we're able to fetch data in multiple ways, factoring in latency. I think the really important thing for you to consider when you're building React apps, by the way, feel free to add teams in Zadah, and then I'll refresh the page and it'll regenerate with ISR. So, I added Khaled and Gabe, but if you want, feel free to fuck around as much as you want, and then in the end I'll refresh the form here. So, what did we look at? We looked at serverless functions, we looked at multiple React fetching strategies, I think for me personally, the most valuable thing I've seen is the numbers of SSG versus SSR verus client-side rendering. Thank you for sharing that those of you in the Middle East, it's quite important, but that's essentially, it is my battery is about to give up, but I have a cable somewhere, it's fine. That's the spirit of the app. Working with serverless. Now, if we wanted to add authentication, authorization, how would we do that? We would use a serverless provider, probably the most famous one is Auth0, and they give you a full API that implements OAuth. We would stitch that together here in our app, and we would have Auth. So the idea is, going back to the diagram, that this is from Vercel, this is from Zada, and if we have another color, let's maybe copy, yeah let's copy this here. Ah, it's time to get my cable. Let me signal my wife. Can I get the cable, please? You got it. So awesome having a wife. It's like a cable delivery system. And more. Focus on the more. Yes. Thank you. So let's plug this in. Hey, no problem Jose, appreciate you. So, if we wanted to do auth, this would become just another service that we don't manage. Let me type that properly. Let's change the color just for consistency, right. And then our app, our site rather would talk to that. You get the idea, this is the essence of serverless. So we are fetching Zada from the API just because we don't want to leak the key. But for example, with Auth0, you may be allowed to fetch directly from your client or whoever, but my site itself is quite lean and quite stateless. I wanna show you two more things before we wrap up and then we can call it a day. Zada is cool because it's fast. Oh, you added some stuff? Let's go reload here. Okay, it's rebuilding in the background. You should see Carla and Gabe rebuild. We have Team Vikings and Null, so it does work. ISR, I didn't do anything. That's why ISR is great. You should have it too if you want to visit. Okay, I wanted to show you a couple more things and then we can call it. Number one, under a feature flag at Zada, you can access it by going to slash flags and enabling it for yourself. This will go away, so don't get used to it. But if you enable the playground, you can actually query Zada directly from here in a Visual Studio Code style UI. So you can do things like zada.db.users.getall or.teams.getall.

And we actually use this internally a lot. So if we go to our blog here, we, sometimes, you know just to have a competition or something, we go here and against production data, I can literally filter where author name is mine and see how many blog posts I wrote. It's actually a global API key, sorry. Zada API key, yeah. And so I wrote two blog posts, I can see how many my CEO wrote, and it's also two.

What are you using for Code Editor in Zada? This is yeah, it's called the Monaco Editor. It actually is the same editor from Visual Studio Code, it's open source from Microsoft and it's this thing so, that's one learning for you. So we can do this with Zada also, this is typesafe, so if you watch my screen and I fuck up the column name, it's like you can't do this query. So it's quite comfortable to use and then of course, if I get this query here, I can go to my app, paste the code and it just works.

That's one thing, the other thing is everything we did with the CLI and the web UI, for Zada as a serverless database, we can actually also just do it from Visual Studio Code here. So like I showed you the web UI and stuff, I really didn't have to. So if we go to Zada learning, there's also your databases and if we look at the home database, we can look at the teams, for example that you made and that's the JSON version anyway of your teams and I think someone's your script tag is fucking up Visual Studio Code. Good job, your cross site scripting actually did work but not in our UI. We can also insert records so I can add a user directly here. So I'll add someone who's 23 years old named you and I can insert this directly from here and then I can if I view users, I can open it in Zara. Did it even insert? Fuck, you're seeing nothing. That Visual Studio Code extension is very experimental so we don't even ship that yet. You have to actually build it from source. You saw why. Those are two things.

The last thing is the database is completely branchable which we think is really cool because over time you're going to wanna make changes to your data and you really don't want to do it in an unsafe way. So if we go to this home database and in our feature list which we didn't actually get anything here, we maybe want meeting notes. You wanna add that as a table. We can do it unsafely by fucking up the main branch or we can do it safely by creating another branch. How we do that is here if we're in this project. Sorry, what I can do is get status. I can check out a new branch. So I'll check out a new branch, call it meetings, okay? And in the meeting notes, if I go back to my code, what I can do is, don't save. What I can do is go to my Zada folder and change the schema. So schema.json. So there's two tables here already. I'll just make another table. I'll say I have a table whose name is meeting notes. This is opinionated JSON. And the columns are an array of columns, right? So columns have a name, which is text and a type, which is string. And we give you auto completion where you can. That basically matches every column we have here. So that looks good. I'm not sure why this is red. Needs a colon. Why? All right, got it. So I made a new table meeting notes and I'm in a new branch meetings. So here, if I run Zada deploy, it says, look, your database doesn't have a branch called meetings. Do you want to start a new branch? Yes. From which branch should I fork the new branch? Main. And so now we've literally checked out a new database brand it says, so for this branch meetings, you want to add another table meeting notes, yes or no? Yes. So now we've actually have another branch called meetings. We can look at it in the web UI and this branch has like a whole extra table. So the main branch is still safe. My users are using it, it's fine. But if I want to experiment, I go to this branch, I have meeting notes, I can work my whole feature in this branch. And at some point when I merge it to main, it's just a zero downtime merge, okay? And that's how also we make databases a lot safer because if you've ever had to migrate a database in production with like hundreds of users, it's kind of scary.

That's a good question, Nadav. Data migrations are really cool. They're handled for your users. There's zero perceived downtime. This is actually the benefit of having a serverless database, right? Because you interact with an API. So we manage the migrations and so on. So how it works is, if you have like huge database, when a request comes into our API, we know, because we run the servers, we know, hey, a server is running and a migration is in progress, what do we do? And we make decisions about that. Sometimes we might create a clone of your database and send that right to both databases, one with the newer schema, one with the older, and so on. That's a great question. The alternatives to Zada, I don't personally, you think, of course, I would say this, but I don't know any serverless databases focused on developer experience. Like a serverless database that gives me this UI with the TypeScript client, the playground, the VS Code extension, nothing. There is no alternative for that. But there are some that are focused on developer experience, right? Probably the closest alternative is Superbase. You may have heard of them like open source Firebase. They give you hosted Postgres. Yeah, Firebase, you would, I think, I don't know, I think Firebase is not open source, but Firebase or Superbase is probably the closest thing because you just get like hosted database. The trade-offs, of course, is with that, it's very opinionated, it's like Postgres. So you have to know SQL and you have to think about that. It also doesn't give you a search. Oh, shit, we didn't even talk about that. Let me share my screen, but please keep the questions coming because we don't have that much time left and I really want you to get something out of this talk, out of this workshop. I think Ali has a valid point. What was that? Ali had a question, you can see in the chat. Oh, how do, Ali, ISR is very cool, but some users will get stale data, it can be a bit of a weird user experience as they won't see the newest theme without refreshing. Solve this, will you then add logic to load a more up-to-date list after the initial page, yes, exactly, that's exactly what we would do because then your static site is still served, but you would still do another request, it doesn't cost you anything, especially if it's pazada, you're fine, you can do as many requests as you want. Exactly, that's good, that's, you've kind of answered your own question. Yeah, especially because of this, like the select has options, right, so you don't even see a flash or anything. In some cases, if it's a blog and your data is really stale, then you'll see a flash of content maybe, but otherwise, no. Using SWR and ISR is one of the best ideas you'll ever have, especially because both of them come from Versel, so they're able to fine tune the details and such. The last thing I wanted to show you, and this no other company does, is you get like a full search engine straight up. Like you can search, I don't, what's the API? I don't, is it objects in tech? I don't even know how to do this. Hello, what do you want? Does this work? Is how to.search is not a function? Is it.db.search? I guess it's, you know what? I tried. Dot, ah, oh, okay. Serverless. It's wow, so I'm surprised by this myself. We can search across every table and every column for the word serverless, and we get back all these results. We can search either all or by table. So the table name is just, for example, Posts Options, and we have tables, and this is an array of tables, and we can also specify fuzziness. Ooh, so if it's a loose match, we'll still get results and so on. Oh, sorry, just this one, I guess. Four, between 0 and 2, okay, 1. So yeah, full search engine, full database. This diagram, exactly, where is it? This one here. So yeah, all of this. Red is database, Kafka, search engine, it's all done. The goal is if you wanna build an app, any app, a dating app, a music app, whatever, anything that needs a database, it's just, everything's instant. You get nice, comfortable tooling and it goes away, and I think we've kind of explored that today. Yeah, with one minute to go, I think we'll leave it here, any feedback questions, comments, prepraised? Just have a last thing there, if you can please explain the Edge functions thing. Yeah, good, yeah, so what was your question about that? I'm hard to, I can't understand the functions of Edge. What do we do exactly? It was like from regional servers, right? Yeah, so you know how a CDN is a globally distributed network of static servers that give you HTML, right? Hey, thanks for the feedback, everybody. I appreciate that so much. Thanks, if you liked it, tweet it. I'd appreciate just a thank you or something on Twitter, so I can also follow you. Yeah, Taimur, it's how a CDN serves stuff from a static computer close to you. Edge functions is the same thing. It's a computer near you that can execute your serverless function. So that's it, Edge function, whereas now the alternative to Edge functions is everything runs in US East, Washington DC.