Deploy and Test Full-Stack React Apps on Cloudflare

Hi, everyone. Welcome to the workshop, which is deploying and testing full stack React apps on Cloudflare. Before we get started with the content here, I'm going to give a quick intro to myself and I'll let Dario intro himself. But my name is Christian Sparks. I'm on the builds and automation team at Cloudflare. So if you have ever used Cloudflare pages or you've used Cloudflare workers builds, basically, I work on that type of stuff. So basically, all of the Git integration, if you're building a static site on Cloudflare, I work on that sort of stuff.

And then Dario Pietrovic. I work in the frameworks team at Cloudflare, where we basically try to improve our Cloudflare integration with the various JavaScript frameworks in the ecosystem. And yeah, the workshop, it's about creating a full stack React application and deploy it to our platform. All done alongside comprehensive testing. This is the agenda. It's roughly divided in three one hour slots. We'll start by a quick introduction to the project, then some light UI implementations, and then we'll deploy our project to the Cloudflare platform. Then we'll have a short break. Afterwards, we'll implement some backend logic that actually integrates our application with some resources from the Cloudflare platform. Then another short break. And we'll finally conclude by combining the server-side logic we just implemented in the previous step with our UI, and we test the whole application. And this will bring us to the end of the workshop.

As requirements, they are pretty minimal. But yeah, just your favorite IDE. We usually suggest VS Code, but any IDE should do. NPM or your preferred package manager. Git, as you saw, we have this GitHub repo and the workshop is around this repository. So Git is definitely needed. The Cloudflare account, since we need to integrate with Cloudflare resources and deploy to Cloudflare. So a Cloudflare account is needed. If you haven't set one up, it takes just a few minutes and it's completely free. You don't have to pay anything or anything like that. So it should be pretty good. And finally some enthusiasm, which never hurts.

And yeah. Yeah, sure. So to give a quick overview of what we'll be doing during this workshop, we'll be building a trading card generator app built using Remix, which is a React full-stack framework, Cloudflare workers, and pages. Yes, I'll drop in the repo link. But Cloudflare workers and some other Cloudflare resources. And here's a little demo of our completed applications. You have a little form here, so let's do example. Then we can click Generate, once we've inserted a title and description. It'll take a few seconds, because it is generating an image. And we'll hopefully see a result in a second. And you can see that we've generated a little trading card, a nice-looking trading card. And this is kind of what you'll come away from the workshop with.

Now, to give an overview of what tech we're building this with, the first is Cloudflare workers. So I'm going to give a bit of an overview, because it's a little bit different from a lot of the JavaScript platforms you might have used before. Typically, people will do stuff in Node or in the browser, but workers is a little bit different. The key is that it's a low-latency serverless runtime, and it's sort of regionless. The idea is that it can run in pretty much any location in the world, and you can choose its placement and make it run near a user, far away from a user, near certain databases that you might have in order to optimize the responsiveness for any user of your application. It's also V8-based, so kind of the same tech as Chrome and Node.js, but there's some API differences. Pretty performant.

And the way that we sandbox it, this is kind of more detailed than you need, but we use V8 isolates in order to minimize cold starts. So what that means is, if nobody has accessed your application in a while on other serverless platforms, you might experience a pretty slow request, so like cold starts of almost half a second or a second, versus with Cloudflare, we try to minimize it to be zero, so there's basically no difference between a cold start and a hot start. It's also pretty cheap. Free plan, $5 a month, there's a lot of requests included. The workshop today can be completed entirely within the free plan with many, many requests there, so you don't need to worry about that. And specifically, the tech that we'll be using is Cloudflare Pages, which provides a combo of static assets hosting, as well as some backend workers capability, which is kind of ideal for our use case today, which is a full-stack web app. I'll hand it off to Dario to talk about React.

Cool, so yeah, the full-stack React framework we'll be using is Remix. Probably everyone here should be pretty familiar with that. But anyway, just to give a light introduction, it's a full-stack React framework with a nice UXDX and all the bells and whistles you'd expect from a modern framework. One thing to mention is that the Remix team is kind of migrating it to become part of React Routers v7. But yeah, anything we'll be using today, it should be pretty trivially migratable anyway to React v7 when it comes, so it's not like what we'll present today, it's going to be obsolete soon. Anyway, what we'll also implement can be implemented with any full-stack React framework or even any full-stack JavaScript framework in general, so it is a bit Remix-based, but the concepts are pretty generic.

As a full-stack React framework on Cloudflare, there are a few other alternatives, for example the big one is NxJS. There are also newer and experimental ones like Quark and 10-steps. But yeah, anyway, we chose to go with Remix because it has very good out-of-the-box support for Cloudflare. It has a polished API for accessing Cloudflare resources, as we'll see in the workshop. We also have a nice starter template in our C3 tool for creating a new Remix project and I can actually very quickly show you what I mean with that. If you're not familiar with our Create tool, it's a simple CLI tool which you can run via C3 and create Cloudflare or your package manager alternative. You can choose where to create your application. There are various options, and as I mentioned, we have an option for Remix. So basically, if you were to use the C3 tool, here we would scaffold and create a Remix application ready for you to just deploy on Cloudflare. Anyways, I was just showing you the tool, but we're not going to use it as in our repo. We already scaffolded the whole application for you. Speaking of which, this is the repo. Christian already shared it. If you can please clone it. Anyways, to give a very high level introduction of the repo, there is simply a welcome section with a link to the slides. I mean, I think you have it, but it's there if you need it. And one important thing to mention, we have a set of GitHubs so that if you want, you can jump to any point of the workshop at any time. So yeah, if you, for example, get lost at any point, or you want to skip an exercise or check the solution for an exercise or anything you want, you can simply check out the various tags, which are listed here. Yes. Anyway, we also live code the various exercises, solutions, and anything like that. So hopefully you should not need to jump too much through tags, but if you need to, they're there for you. We can start with the first exercise. Here we are also listing the various GitHubs related to this exercise. Anyways, for each exercise in our workshop, we have a readme file, which you can find under exercises. And yes, this first exercise, it's regarding implementing the form of our UI. So right now we have a simple partially implemented UI, and the task of this first exercise is to implement the form with the action and loader logic, so the backend integration logic for that. So yeah, we'll give you a few minutes to get acquainted with the repo and start the project and start working on the first step, then in a few minutes we can live code the first step together and we'll also continue with this structure for the other steps. So yeah, if you want to get started with the exercise. And by the way, at any point if you have any questions or anything, just shout or message us in chat or whatever you want. So let's actually start looking at the solution for the first step together. And let me actually... I already forked... How do I get rid of this? Okay, I already cloned the repo. So let's actually do a simple npm install. And we can start the application with npm run dev. So we do get our... So this is the starting application.

And the first exercise was to... The first step is to actually update this view to the form. So if we go to the first readme and this asks you to basically update this index.ts file. So here, let's see, the first step asks us to firstly update this card details variable. So instead of having those placeholder values, we actually just want to have null. And then we also want to make type script heavy here. And then, if there is no... If the card details variable is null, we do want to implement our form. So we'll be using the form component from Remixer. And here, we want to have two fields. So an input, which is for the title, and a textarea, which is for the description. So yeah, this is basically it for the inputs. We also want a button, which is for generating our card. Lastly, we specify here that the form should have a post method. And it shouldn't have any action. Lastly, I hope... This is as clear as I managed to get it. But basically, for you to inherit our styles, you should follow this sort of structure. Anyways, I can here show you what those meant. So in the form component, we actually want the card form class. Then we actually want to wrap our inputs inside a div with the class name of card. And let's move this here. Then we do want an extra div, which will be a placeholder for the card image. So there it is. Then let's add the classes for the title and description. So, card.title and card.title.input Here. This should be description. Okay. So, lastly, our button should have a class of btn and btn.generate. So, if we now go to our application, we can see that we have the form as we wanted. And we can input some data here. We can generate and, you know, things break. That's then the second step. So, we want to implement an action so that we handle the form submission. So, yeah. Now, if you – we give you around five minutes or so to do the second step. And then we let go also the second step solution together. We'll be linking the diffs throughout. And you can also check out the solutions locally as well. Just so you all can follow along. I'll start the – like, putting the second step of the exercise. So, we implemented our form. Next up, we want to implement the action. So, to implement the action, let's go here. And we want to export a function which we want to be a sinker. And this function needs to be called action. It takes some arguments which are action function args from Remix. And from the arguments, we can get the request. So, from the request, we can get our form data from which we can get the, you know, input data inside the form. This needs to be awaited.

And here in our form data, we can get the title and description. And we want to assign some variables to those. So, now, we have our title and description. The exercise asks us to also log them. So, a simple console log should do. And the title and description.

Next up, we want to wait for a second to simulate a back-end delay. So, we'll just await a new promise. And in the promise, we can simply do a set timeout of 1 second. So, after waiting for 1 second, we can then mock a card ID. So, just a card ID. Equal a card ID placeholder. And finally, we return a redirect to this URL. To this path, I should say. So, with this in place, if we go to our application and refresh it, we should be able to put a title and a description in our form. Click generate. It takes a second, but then you see we do get redirected to this URL. And in our terminal, we do get our title and description. So, yes. This was the second step. As you can see, the UI doesn't change after you submit your form. And that's what the loader is needed for. So, that's the next step in our exercise.

So, yeah. I'll give you another 5 minutes to work on the third step. Yeah, let's actually live code the third step together, and Christian will look into the node-defined issue in chat. So, if we go back to our ReadMe... The first step was asking us to create a loader. So, for the loader, we again want to implement... implement an export and async function, which is called loader. The parameters here are loader function args, from which, again, we can get our request. So, once we get the request, we want to get the card ID, which we actually set in the action. And to do that, we need to create a URL object. So, new URL. And we pass the URL string from our request. From the URL, we can get our card ID. So, URL search parameters, get card ID. And what we want to do here is if card ID... If there is no card ID. So, let's actually just check if it's faulty. Then we simply return null. Otherwise, we want to return a placeholder object. So, return this object, which should satisfy this card interface. Satisfy this card interface, it should have a title. So, placeholder title and description. Placeholder description. And finally, there is also an image URL. And this should be it for our loader. Finally, we actually want to read this data from another component. And in order to do that, we use the use loader data hook from Remix, in which we also want to specify that we are using the types of the loader, so that we will get a nice typing for our card details.

This should actually be it. If we now go to our application, you can already see that we do get our UI, not the form anymore. But let's try again. Here I can put a title. Description, I can generate. It will take us a second, but then our form works as intended. So, with this, we completed the first exercises. We have all our UI packet in place. And now we will want to implement backend logic to actually provide actual real functionality to the application. Before that, we'll also do some setup for the cloud integration and also deploying. That's what Christian will do next. Could you try and help out in the chat and then I'll take over? Sure. Then stop sharing.

So I'll quickly take over here. One second. Sorry, I gotta quickly. So, obviously now we should have a very basic front-end application, but that doesn't really give us any functionality. So, we want to add some statefulness so that our application can do some cool stuff like generate card artwork, as well as save and share our cards.

And to do this, we're gonna use some useful Cloudflare resources, specifically those are called bindings. So, bindings are kind of a concept that are somewhat unique to Cloudflare, but the idea is that they do two key things. They grant capabilities and permissions. So, for example, your worker has access to a specific resource. So, that might be an R2 bucket, that might be a key value namespace. I'll explain what those are later in a second, but they basically give you access to maybe some data or an API. And then they also inject the services API into your worker's environment. So, the idea is that, oh, yes. Can you send the solution to the previous step? They also inject your services API into the workers environment. So, the idea is that, essentially, you don't have to import any library, you kind of get the library imported and injected into your worker. And we'll figure out how that looks, what that looks like in a second.

But to generate and save cards, we'll be using the following bindings. Workers KV, which is basically a key value store. So, you store some data in some key. R2, which is basically equivalent to S3, if you've ever used it, so it's blob storage. And we'll be using that to store the images from our cards, as well as worker's AI, which basically allows us to do some generative AI things with workers. So, in our case, generating some images.

So, you might be asking, why does Cloudflare use bindings as opposed to what the typical method would be, which is setting up an API token and then using that API token with a library per se? The reason is that you have lower security risks, because you never have an API token to be able to leak. So, you're not copying and pasting API tokens. You also don't need any boilerplates, so you don't need to set up your library or configure an API client or something like that. It also gives you pretty clear visibility on resource usage.

So, now let's actually try and deploy our very basic site and set up some bindings. So, this is going to be a bit more guided. So, if you all want to follow along with me while I do this. Let me pull this up. I'm actually going to, let me actually close this one out. Awesome.

Alright, so, if you haven't, if you've completed all the exercises, I'm currently just on the EXR 01 tag, so just check that out. But if you've completed the exercises, you don't necessarily need to do that. So, let's open up the O2 Bindings section. And if you all want to look at this specific exercise, there's technically two of them. There are two options. There's the pure KV version as well as the pure R2, or the R2 plus KV version. We recommend the R2 plus KV version. So, I think we can link that. Sorry, oh, you all only see the slide. Sorry about that. Oh, whoops. Give me one quick second. Let me share my whole screen.

Alright, I'm back. Okay, so I'm going to pull up this here. So first, let's log into our CloudFlare account. So, if you haven't logged into your CloudFlare account already, let's do that in the Wrangler CLI, which is just a useful way for us to manage our CloudFlare projects within your terminal. So, let's do npx wrangler login.

And this will basically just prompt me to log in. And it should redirect me to the dashboard. And it just gives me an authorization prompt. And you can allow that if you haven't logged into Wrangler yet. I'll let you all do that. And once you've logged in, you can do npm run deploy. And what this will do is it'll prompt you, if you haven't created this project already, which you likely have not, it will prompt you to create a new project. And then it will also just upload and deploy our pages project. So, I'm going to run this. Ideally, you should get this prompt. Create a new project. You can just click through the production branch name, just leave it as the default. Then we should get an upload in a second. And I'm going to open up the CloudFlare dashboard super quickly. Yes, so it should give you a result, this pages.dev domain. This won't work for the first two or three minutes. Yes, it does take time until the project starts being available. So that's normal and expected. And in the meantime, we're going to try and set up some bindings. So, you can see that this will show up with a blank page. That's just because we're configuring the domain and stuff. It'll show up in a quick second. But in the meantime, you can see that in your CloudFlare dashboard, which is at dash.cloudflare.com, you can see that you should have a new project here that has one deployment and has some settings. And they're basically the defaults. Now, once we have these bindings, let's go, or once we have this project, let's try and set up some bindings. So, we want to do some setup to configure our workers and pages bindings. So, as I said before, these bindings can bind permissions and an API of a worker. And we've included one binding to start, which is configured in the wrangler.toml. So, that wrangler.toml in the root of the repository, so right here, you can see that we have the name of our project, compatibility date, the build output directory, and then we have this one thing called ai binding equals ai. What this does is it exposes an environment variable for pages, or for pages to access the ai type, like the ai API. And we'll talk a little bit about how to use this binding later, but all you need to know is just that we've included this in there for you. And if you look in the dashboard, right here under the binding section, we have ai set up as a binding. So, now we're going to create some storage bindings, so for kv and r2. So, first let's create a kv namespace. So, this will be npx wrangler kv namespace create trading cards. So, I'm just going to paste this command in. And... Oh. Namespace, oh, whoops. I need to have, I've created this namespace already. Trading cards, short. The name doesn't really matter that much, because you can just paste in the configuration. So, we can see this ID here, and what we want is we want to use this ID in our configuration file. So, in our wrangler.toml. So, if you look in the wrangler.toml, there's this kv namespaces thing here. And let's... Actually, it gives us a little useful snippet here. We do want this binding to be named kv, though, importantly. But the ID is going to be specific to you. And this is scoped to your account.

Now, secondly, or I'll let people go through this and see if they have any errors. And then, once you've created that kv namespace, let's also do the same for an R2 bucket. So, that's basically the equivalent to an S3 bucket. So, we're going to do npx wrangler R2 bucket create, card images. I think this might not be a unique bucket. Yeah, I need to change the name of my bucket because I've created it too many times. And this one, you might get an authentication error. The reason is is that you do need to have a credit card linked to your account. In the case of using R2, it's going to be totally free. But if you don't want to add a credit card to your account, there is an alternate, purely kv version of this. But it shouldn't cost any money. Anyway, throughout this workshop, it's just a matter of like curbing abuse. And then, we can paste in this here, the bucket name that we just created. And let's save this wrangler toml. And now, we have these three bindings that we've created. And how do we actually use them in our code? Well, in order to use them in our code, we'll first do npm run build, and we can also do npm run cftypegen. And what that does is it kind of generates the type interface for our worker. Because if you remember, bindings are both configurations and they're also APIs at the same time. So, the configuration file kind of defines the types for the API that we'll be using in the next exercise. And this interface is output in worker configuration d.ts. Now that we've configured all of this, and I'll wait for everyone to follow along a little bit, but now that we've kind of set up this configuration, we can deploy our site again. So, we can just do npm run deploy, and this is going to create a new deployment of our site. It's going to use the exact same project that we just created. And, ah yes, so that error, yes. So, if you run into the R2 error, it's because that error is just because with R2 we gate it behind having a credit card linked to your account. You can, essentially, if you go into the dashboard and you go into R2 object storage, it should give you a prompt to insert credit card information. If you don't want to do that, you can follow along purely with the KB version of this, but either way, it's mostly just like an abuse mitigation thing so that you don't create like a ton of R2 buckets for free, but everything is like within the free tier. Does that make sense if you run into that R2 bucket error? You can also follow along this KB bindings version. So, yes, so as in the difference between the KB and R2 versions, so like, basically, KB is a key value store and in the regular version of this, we're basically going to store card metadata and the bucket in R2 is that we're going to store the image data in R2. And typically KB is usually ideally for metadata and things like that. And then R2 is useful for like blobs. So for example, images. Now there's nothing preventing you from storing image data in Workers KB, but we kind of want to demonstrate some more example or some more opportunities to try out bindings. But does that sort of give a clear ish explanation? But if you look here, you can see that we've created this new R2 bucket and then we've also created a KB namespace, which is one of these. And in addition to that, if we look at the app that we just deployed, there's a new deployment and in the settings section, we actually have our bindings configured here. So they're associated kind of with our environment.

Now that we've had a bit of a break, I'm going to start off with exercise three. Let me just paste in, it's exercise for what it's worth. If you were unable to set up, like fully set up like the deployment and binding stuff, no worries, everything, you can still continue with this. Everything is possible in local dev anyway. And this is just kind of a little bit of setup to intro you to like what bindings are, but we're going to go back into some more coding stuff for the moment. And let me, let me just share my whole screen because this is going to be short. So now we're moving on to exercise three, which is kind of the card manager, class implementation. Now I'm going to, let me just quickly pull this up. So basically, what we have now is we have our, we have our regular application, but we want to implement some functionality.

And let me, I just dropped in the exercise link. And let me, let me just share my whole screen because this is going to be short. So now we're moving on to exercise three, which is kind of the card manager, class implementation. Now I'm going to, let me just quickly pull this up. So basically, what we have now is we have our, we have our regular application, but we want to implement some functionality. And we have kind of a little scaffolded interface for you all to implement to create some functionality. So in this case, let's start by running some tests. So we're going to verify that we can test things. So you can see that we have, we have two series of tests here. If we look, you only need to implement one of these files. But if you look here, we basically have this card manager class. And the idea is the goal of this whole exercise over the next hour or so is basically to implement these functions.

So the card manager class, and this exposes some methods that we'll be using in our actual remix application in a second, or later, to kind of manage the functionality. So this card manager class exports a couple of methods in exports generate card image, generate and save card, getCard and getCardImage. And these are generally pretty self-explanatory. And we have two implementations of these classes, the kv version, or the r2 version. You only need to implement one of these. And then we have two test files for each of them. And you only need to want to implement one of these test files. It's what we intend. Now, if we go to the exercise, we can see that we kind of have everything stubbed out for you. And the first step is to implement and test the generate card image.

So basically the idea of this is that we want to implement this function here, the generate card image function. And then we want to test it using this, by filling in the info here in this test. And to give you a super quick introduction, you can access your bindings with this.env.something. In this case, we have env.ai, we have env.kb, and env.r2. And those are associated with each of the bindings. For the generate card image section, you only need the AI binding and ai.run. And we provide a link to some documentation to show you how to generate an image with Workers AI, and some info on how to test this. In this case, we use VITEST Pool Workers, which is the VITEST testing integration with Cloudflare Workers. Basically, it runs a series of tests in the Workers runtime. And it's pretty straightforward and integrates with VITEST well. VITEST isn't super complicated. The important things that you need to know is that it exposes some EXPECT functions. So you can like kind of EXPECT functionality as well as MOC functionality. And we go into that a little bit. But yeah, I'll give everyone around five to 10 minutes to try and implement this. And then we'll go ahead and live code the generate card image function. And let me know if anyone has any questions because I know we're kind of switching gears into some more backend-focused, like Workers-related code. And also one important note is that if you ever end up seeing any strange test results, so like failed to pop isolated storage stack frame, it tells you this in the test results, but this is usually because you failed to await an asynchronous function. I run into this all the time and I always forget. But that's probably the most common error you'll run into. And as a reminder, you can always just check out EXR 01 start because that's where we're kind of keeping this part of the exercise off because we can try and implement some of our card manager, some of our card manager classes. I'm just going to try and get started with this generate card image method. So we remember before, basically what we want to do is, the way that we do this is that we want to essentially implement the functionality for generate card image, which is pretty straightforward. What we want to do is we just want to output the results of this.ai.run. So if we look at the Workers.ai, or let me share my whole screen. If we look at the Workers.ai binding API, we can see that the inputs here, we pass in a prompt, let me pass in env.ai.run with some model name. And then that outputs a response stream. So pretty straightforward for the implementation.

So what we want to do is we want to create a prompt. So in this case, we can do const prompt equal, or let's call this input equals prompt. And then I'm just going to paste this in. Actually, we want a templated string. Paste this in and I'll do title equals equals card.title and description equals card.description. And what this is, this is just a prompt that we're passing into our stable diffusion model. So it's sort of a little bit of prompt engineering, which is fun. And then what we want to do is we just want to do const stream equals this.env.ai.run. Sorry, this is a little bit of a typo here. We want this.env.ai.run. And this accesses our binding. So the AI here is our binding. And then the function here is just an injected API. And you don't need to do any set up for this. It just should work. If we copy this text here, copy this text here, and then we pass in our input. This should give us an output of a text image output. And we should just be able to return the stream. And an AI text image output is just a readable stream UNT8 array. So awesome, so we've implemented this function.

Now, let's try implementing the test for this function. So in the case of workers.ai, the issue is that there's no local dev support for workers.ai. And this might be weird, but I think it kind of makes sense because you don't want to download all of these like giant AI models onto your local machine. But we still need to be able to test our functionality. So in this case, we have to kind of mock the response from our AI function. So let's create some sample image data. I give you a little bit of a snippet here to generate some image data. And this basically creates a fake readable stream with just this array 1234. And what we can do is we can use vi.spyon. And what vi.spyon does is it replaces some implementation of a function, so env.ai.run. So what this does is it spies on env.ai, which in our case is any calls to this.env.ai.run. So it basically just spies on that function. And in that function, we want to mock resolve value with the stream. And what that means is that we're mocking the result of this run function. So whenever we run this function locally in our test, if we run generateCardImage locally in our test, we're replacing the output of the ai.run function. So it's outputting this fake test data that we wanted to. And then we can use expect. Oh, oops. I think import is a little bit weird. But we can do by test expect. So we can do, or actually we want to run our function. So cardManager.generateCardImage. And in this case, let's do const card. And we can do title equals title. And description equals description. And this is just like a test card that we'll pass in. Let's just do card. And then if we do const stream result equals await generateCardImage. So we're generating our card image. So we're running the card manager function.

And then we can expect the result. So we can expect that our stream result to strict equal our stream. And in this case, we're just asserting that our mocked response from our ai.run function is the same as the response from our card manager. So let's actually... Our npm run test. So let's run the test. And this hopefully should pass. Awesome, so this test passes. And if we were to like to not... If we were to break this test, it should just like, it did throw a new error. This test should fail in this case. But we're just verifying that the result of this function is as we expect. And the functionality for both the R2 version of the card manager and the KB version should be exactly the same. And let me just send that out.

And you only need to implement one for context. And now I'll give you all some time to try and implement the generate and save card function, which I think is probably the most complicated part of this exercise because we'll be using KB and R2 in this instance, or two instances of KB if you're doing the KB version of this. So I'll give you all about five to 10 minutes to implement this exercise. So I'll go ahead and start live coding this generate and save card function. Basically, just storing the card in KB and R2. So let's kind of like code this. So in this case, what we want to do is we want to first generate a uuid for our card. So this is basically just going to be card ID, let's say card ID. And then to do this, we just can use crypto.random uuid, which is just kind of a standard function here. And then what we want to do is we want to insert the card metadata as a key value pair. What that means is we want to insert the card title description and image URL under a specific key. And we can do that with this.env.kb.put. And basically, that inserts a value into KB. What we do is we do card ID. And then what we want is to insert our stringified JSON data. And what that is, is it's just going to be like title, card.title, description, card.description, and then image URL equals imageUrl. Image slash card ID. What this does is it saves our data into KB under the key card ID. And let's await this. And then in addition to this, so we've saved the card metadata, but we haven't saved the card image yet. And we want to save the card image to R2. So we can do await this.env.R2.put. And this is a similar API. And we can put it under card ID. And we want to put the value in there. And we actually need to call out to our previously implemented generate card image function. So first, let's do const image equals await this.generateCardImage. And let's pass in the card because this is the same kind of parameters with the title and description here. And this gives us a readable stream of Uint8 array. Now, one thing that's a little bit weird about this is that we can't actually just put this image into R2. What we actually need to do beforehand, we actually need to convert the data type of the image. And we have a little helper function for you all to do this for you called convertReadableStreamToUint8Array. Basically we just want to pull out this Uint8 array out of this readable stream before we can put it into R2. And in order to do that, we can just do, I'm going to just wrap this function in convertReadableStreamToUint8Array. Let me import that utility function. And let me save this image.

Right, cool. So we've now saved the image to R2. Now, we've done basically all of the business logic that we want. We want to do one final thing, which is return our card ID, which provides us with the card ID that we just generated and saved. Now, this might look a little bit different if you're doing it with KV. In the context of KV, I'm just going to pull up the solution here. But in KV, instead of doing R2.put, you're just going to do two different KV.puts. This is just a little bit different from how we do it, but it's effectively the same functionality. We just throw it all in a promise.all block. But basically you need to prefix the data because you're saving it in the same KV namespace. But it's pretty much the same implementation.

Now that we've created the implementation of this, we can actually test the result of this. So let's implement our tests here. So we're actually going to need to do the same binding mocking functionality that we did in step one. And create like a sample card. The reason is that, if you remember here, we actually call out to generate card image, which means that we need to mock AI.run. But importantly, we don't need to mock KV or R2 locally, because the way that the worker's testing environment works is that we provide basically a mock subversion of R2 and KV that automatically work locally. So they work basically like you would expect in prod.

So let's just start implementing generate and save card. So let's say we do const card ID equals await card manager, card manager.generateAndSaveCard. We're going to pass this card in. And what this does is, as we said before, it inserts into KV and R2 and generates the image. So what we want to do here is we want to assert that we've saved the correct data to KV and R2. And you can do this by accessing the env variable. We provide in the testing environment, there is an env variable exposed that we can just access here and access them just like we would inside of our implementation.

So we can actually do, in the case of env.kv, we can do env.kv.get. So let's actually get our card ID that we just generated. const kv card equals await env.kv.card.get. And we can actually output that as JSON. Let's just typecast this to a card. And then we can just expect that kv card.title to strict equal card.title. And we can see that this should ensure that we are getting the correct result from KV. So let's actually run this test. Awesome, that passes. And if we were to change this to foo, this should fail. And cool, so we see that we're getting the correct kv card data from KV. And then we can also assert the other values. So in this case, we can do description. And then in addition to this, we've also inserted some data into R2. So what we wanna do is also R2 image. So we want to await env.r2.get card ID. And this gets us the R2 data back from our store. And in order to do this, we can expect R2 image.arraybuffer. We're just going to access the array buffer here. This is actually an awaitable function. So we're doing some conversions here. And we can set it to be strict equal to strict equal R image array.buffer. There are many ways that you can assert it, but this is just the way that I'm asserting it. There's probably some, you can assert the readable streams, you can assert like some blobs, but this is just one way that you can do it. And then presumably, this should also pass. Awesome, cool. So we've asserted that we're storing the right data in KV, and we're asserting that we stored the right data into R2. So awesome. So, and the functionality or the testing is gonna be very, very similar for KV, except instead of getting from the card ID, you're gonna just get purely from KV with some prefix. But now that we've completed that, I'll let you all implement the get card function, which should be fairly straightforward given that we've already been getting some data from KV in our tests. So I'll give you all like a little bit less time to do this just because it's a little bit more straightforward. So now that we've spent a little bit of time, let's go over the life coded section for get card. So what this does is we basically just want to read some card data from workers KV, and then return that card if it exists. If it doesn't, then we'll return null, or if it's like invalid data, we'll also return null. So what we want to do here is const card equals await, if we remember from the test before, we can do env or this, env.kv.get, we can do card ID because that's our key in this instance, and we can output that as JSON. And let's, we actually don't really know whether or not the type is valid, but so let's do a null check if card is new, let's just return no. And then we can also do, we have a little type guard for you so if is not a card, we have a type guard called is card, we'll just import that and basically, if it's not in the data type that we expect, so like if current has an extra value or doesn't have, or if card doesn't have like the correct parameters or something, we'll fail and we can just return null, otherwise we know that we have a card and we can just return card, awesome. So pretty straightforward implementation for this function, just some basic gets and nulls checks. And then once we've implemented this, let's test it and let's test in two cases, so a null card which is pretty straightforward we just do await const card equals await cardManager.getCard null card. This is not going to exist because we haven't inserted any data into KB, so let's just expect card to be null and that should pass. So let's run this test. Awesome, cool. And then secondly, we want to try and assert some data with a non-null card. So let's const card to insert or card to put, let's say, and let's put some data that we expect. So title title, description, description and then maybe image URL, example.com slash image. And then we can do await env.kb.put and we can just do key, or let's just do like const key equals, let's actually do a random UUID. Key, and then JSON.stringify card to put and then we can do cardManager.getCard from that key that we just used, card equals and then let's just assert that the card is strictly equal to what we put in there. So expect card to strict equal our card to put, so let's just verify that these cards are the same, that we are getting the same result that we expect. And it looks like this failed, isolated storage failed. Ah, that's, this is a classic error, I forgot to await, so this should be resolved.

Because, awesome, so now that we awaited, our test is working and we're getting the right response. So now the final step is to implement and test the getCardImage function, I'll let you all implement this for a couple minutes and then we'll go over the solution. Oh, and I forgot to mention the KB solution is almost exactly the same in this instance, you're just adding a different prefix to the, you're just adding a different prefix to the key. But otherwise, pretty straightforward. But now let's try and implement the getCardImage function.

So pretty straightforward, similar to the previous method. So let's do cardImage and we want to get it out of R2, so that's await this.env.r2.get, and that will be our cardId passed in, or let's do r2 image, actually, let's leave it at that. And then we return r2 image.body which is just an array buffer, or not an array buffer, it's just a readable stream. And if it doesn't exist, it's undefined, we can do, we can just null coalesce that. So basically, we'll return the stream if it exists or just return null. Pretty simple implementation.

Now let's actually implement the tests for nullCard. This one's going to be a similar setup to our KB version. GetCardImage, let's just do cardImage. This one is going to be pretty straightforward. Awesome, should pass, hopefully, yes, there we go. And then we can do kind of a similar thing to that we did before and insert some data into R2. So const, let's create some uuid, const equals crypto.randomUuid. And then let's create some sample data. So I'm just going to copy this uint8 array. And then I'm going to do env.r2.put uuid and then image array. So we're putting something into R2 and then let's actually const R2 image equals cardManager.getCardImage and then uuid. And this should return us a readable stream. So expect this returns, oh wait, I need to await this so I don't get failure. So let's do R2 image to strict equal R image array. But importantly, if we notice here this is a uint8 array. And then this is a readable stream of uint8 array. So let's use our helper function from before. So let's just do await convert readable stream to uint8 array and pass that readable stream in there. So now both of these should be the same data type. I believe, well, let's just do as readable stream, I'm just going to as readable stream. I'm just going to typecast this. Ideally you can also just like null assert this. Either one is fine because the test will fail if it is not asserted correctly anyway. And then these tests should pass. Awesome. So now we've implemented this. If you are in doing the KV version of this, it's going to be pretty much the same, except instead you're going to be inserting into KV under some key prefix. But yeah, this is basically the implementation for our cardManager. And I'll let you all have a little five-minute break. And then we'll work on integrating the UI and the backend code together. I'll let Dario do that after that break. After we've implemented with Christian our backend logic, we now want to actually integrate this backend logic with our UI. And this is the forfeited side then. This is straightforward. As we saw in the first step, we implemented our action and loader. And what we want to do is now actually in those functions use our cardManager class. So first step, integrating the action, then the loader, and then we have an image route that we also need to integrate with our backend. So anyway, let's start with the first step. And let's take five minutes to...

I'll give you five minutes to work on this, and then we can work on the solution together. One note, if you are using the KB version of this implementation, you might have to go into... Let me pull up the file. You'll need to swap out the default implementation because by default we use the R2 implementation, but you'll just need to modify this file as necessary to swap to KB. Otherwise, you can just leave that file as is.

Let's actually work on the solution together. Let's open our VS Code. And so this was the state of our application. We can provide inputs, and we get to place all the results. So if now I go to the Fortecsize Ritmi, and we check the first step, we want to integrate the action with our card manager. So we want to go in our index file and update the action function. And by the way, one thing that you'll notice is that here I have a bunch of extra validation and what not. This is just an optional step in the first exercise. So if you don't have it, it's not necessary to have it necessarily. You don't expect it to. Anyways, so what this step is asking us is to now remove the log and the fictional sleep. Then we want to access the Cloudflare bindings. And in Remix, you can actually do that via this context object that is provided for you in the action arguments. Once you get the context, you can access the Cloudflare bindings via context Cloudflareenv. And this is what we'll be using to actually, what we'll be getting and passing it to the card manager constructor. So we can now create a card manager. And to this, again, we can use the context Cloudflareenv. So in this way, we simply create our card manager. And instead of now generating a placeholder card ID, we can just use our card manager running the generate and save card. And we want to pass our title and description. Here, TypeScript complains a bit just because it doesn't understand that title and descriptions are strings. So let's just quickly typecast it. And in this way, we also need to await this. And in this way, we do get our card ID. So now instead of having some placeholder mock implementation of our action, we actually have a proper integration with our backend. So yes, this was the first step.

Next up, it's updating the loader. So let's dedicate a few minutes also for that one. And we typecast that one as well. Let's work on the second step together. And here, it's just implementing the loader, which is going to be pretty similar to what we just did with the action. And yes, again, we do get a context from Remix itself. And so again, we want to create a card manager using the ClutterBindings. We can do that after having checked that we do have a card ID. And finally, instead of returning a placeholder object, we can use our card manager and get the card based on the card ID. So this should actually be pretty much it for the loader. If we go to our application, we should be able to provide some data like... and generate a card. So the thing should actually work now. Let's see. Yes, everything is working as expected. The only thing is that you can see that we do not get the card illustration. The fact is that we are actually generating and saving it, but we haven't implemented the API route that serves the image to our application. And that's the third step. So yeah, let's take a few minutes to also implement that one.

Okay, let's maybe quickly go through the third step. The first step, as I mentioned, was regarding implementing the image router, which is this file that we haven't yet worked with. So what's required here, we do want to get, first of all, the card ID from the route's URL parameters. This is something, again, that Remix provides for you. So in our loader arguments, we do get the params field which we can use to get the card ID. So params get... So it's actually an object. So we do get the card ID from the param subject, and here we also want to get the card bindings from the context that we'll be using to create our card manager. Then we can generate our card manager. So again, card manager equal new card manager and provide the cloud bindings. And what we want to do here, we'll call our getCardImage function so that given a card ID, we will try to retrieve the image for that card, and we do provide our card. We get type error here just because card ID could be undefined. But it's actually, it can't be undefined because of the Remix routing, but it's not aware of that, so we have to add this non null assertion. So in this case, we do get our card imager, but since we are just retrieving this from our storage, it could be null. So in that case, we want to return a 404 response. So basically, if we try to retrieve an image from a card that we actually haven't generated, or if something went wrong and we don't have the actual image in our storage, we do want to return a 404 response. And here we can say not found. Otherwise, we return a normal response, return new response, and in this response, we return the actual stream card image. This should be not a card image. And here we also need to provide the content type error set to image PNG. So this should be pretty much it if we now go to our application, you can see that we now are actually retrieving the image correctly. So this pretty much integrates completely our UI with our backend, completing the application.

Next up, since our application is completed, we can proceed with some E2E tests. What we've been testing thus far with Christian has been more of a unit or integration testing. And what we actually want to do now is actually doing the full end-to-end integration, end-to-end testing in which we actually integrate with the browser and check that the whole user expected behavior of our application is there. We'll be using playwriter to do that. It's a popular E2E testing framework from Microsoft. There are other alternatives, but this is one that we found quite nice to work with. That's our pick for the E2Es here.

So we can proceed with our exercises. The exercises, sorry, the exercise steps here are the initial ones are a bit prescriptive. So we'll be doing the first three exercises together. And the fourth, it's back to a standard exercise, which we will give you some time to do on your own. As the first step of our exercise, we simply want to install playwright. And we want to set the E2Es directory as the directory where we will have our tests. We don't care about GitHub. And we do want to install the playwright browsers. So once it's done, you can see that playwright is ready and it also suggests some useful commands we could use. And yeah, this is actually just the first step of our exercise.

Secondly, we actually want to tweak the playwright config file. And that's because we do want playwright to run the application using our wrangler CLI. This means that we actually want to run our application in the worker's runtime so that it actually matches the as close as possible, the actual production behavior. And for this, we will change the command for playwright to start the dev server to preview, which we can see in our packages that it runs our CLI for. And we also need to change the port to 8788. So this was the second step.

And the third step is the tricky one. So we have this issue in which we do not actually want to run the AI inference during the tweaks. There are a few reasons for that, but mainly because, as you saw, we can take a bit of time for the image to get generated, but also it can incur some cost to run the AI generation often. So we actually do not want to do that when we are simply testing our application. So in order to do that, we need to introduce a new tool scripts to our packages. Here. And basically, these are for simply running our application with this binding. This is a test binding, text binding, which we set which is called mod, and we set it to this e2e-test text. So we are setting this binding, which will be then checking in our code to see if we are in this sort of e2e testing mode. Once we added these scripts, we actually also need to update our playwright configure so that it actually runs our application in testing mode. And next up, we'll be tapping into this a bit more advanced Remix API, which actually allows you to customize the load context that your actions and loaders get. So we actually want to change it so that if we are in this e2e testing mode, instead of getting the real AI binding as we have been getting thus far, we will get a mocked version of it. In order to do that, we simply want to go to the load context TS file. Here, we have actually some very simple copy-paste, but we just want to import the right things. And then we simply copy-paste. I didn't copy the right thing. Let's go back. So we simply copy this function. Let me remove all the classes and save. So this is a simple function in which, again, we check this text binding from our ENB. And if we are in testing mode, instead of the real AI binding, we'll be setting an AI morphed binding, which we already set up anyway ahead of time. We already implemented ahead of time. Once we updated this file, we actually need to use this new function in two places. One is this functions path file, which is basically what starts your pages application. And again, we simply copy-paste the correct changes. So right now, we kind of let Remix know, okay, instead of the standard, the load context, you should use this customized load context. We also want to do the same in the vid-config.js, which doesn't affect the preview and the deployment version of the application, but this is simply to keep in line what you get when you're running the application in that mode using vid and when you actually preview it using our CLI and production.

So we can also update the file here. And once we made all these changes, we can then run our application in preview test mode. So this actually builds the application and runs it using our CLI. This is the URL with port 8788 as we saw earlier. And here you can see that we still have our application and if we click on generate, it's actually returning right away, so this actually shows us that, yeah, the I binding is actually being mocked and we do not get an actual image in this case. So that's exactly what we wanted.

Next up, we want to use player code generation to actually interact with this preview in testing mode version of our application, interact with the former and assert that we actually get the expected result once you submit your form. So this is the fourth step of the exercise which we'll give you some time to implement and then we'll do it together in a few minutes. Cool, so if you want, let's solve the exercise together. Let me go back to my VS code. Okay, what now the fourth step was asking was to run the preview test and in a separate terminal, run npx play write code gen and provide our URL. So what you get when you do this is actually a browser window with the play inspector and you can simply interact with your application and play write will generate some testing code for you.

So once you do this, you can actually see that play write generated a bunch of testing code for you which we can just simply copy and paste in our e2e test files. So you can just create a new spec file or what I'd be doing now it's simply override the example e2e1 that play write generates for us. So I go here and I just copy the code that play write gave us. I kill now my processes and if I now run npx play write test this will actually run our test and we should see it pass. We should also kind of slightly tweak the test for example, we are testing card generation. I clicked more than once, this we should remove it. I made it I, oh no. Yeah, I kind of selected the wrong element, I think.

And then, yeah, everything should be as expected. Just for a sanity check we can also try to break the test. For example, asserting the wrong text as if the element contains the wrong text. And another cool feature of playwright is that you can actually provide this UI flag and you can run your test with this UI presentation. So if we actually now run this test here we should see that it should fail. Oh, I did run it by mistake. Because at some point it kind of can find the text I just broke here. But if I do fix it and we go back here now I should be able to run the test. And as you can see, everything is passing and it's actually saying, okay, the text is correct. So yes, this was the exercise, the fourth step of the exercise. One thing to notice is that we end up with some pretty brittle tests. Like for example, a playwright does try to use the best locator for your elements, but it can't always get things that are perfect if your code doesn't allow for a more specific and robust selector for your elements. And in this case we can see that playwright sometimes just located stuff as divs and getting the first or the second or getting elements by placeholders and stuff like that. So the next step of the exercise is it's actually changing our code so that it's more easily testable and playwright can actually generate more robust and stable locators for you. So that you can make changes and the test won't break just because you change something and instead of a div you have a span or whatever. Since we are not doing too great on time, I'll probably just live code the solution if that's okay. And for that we actually want to go to our index route and let's go here and let's see we have our form and our inputs.

So the next step of the exercise is it's actually changing our code so that it's more easily testable and playwright can actually generate more robust and stable locators for you. So that you can make changes and the test won't break just because you change something and instead of a div you have a span or whatever. Since we are not doing too great on time, I'll probably just live code the solution if that's okay. And for that we actually want to go to our index route and let's go here and let's see we have our form and our inputs. For in the inputs we do want to set this data test ID attribute which is something that playwright will recognize and here we can do like title input. We can do the same for the description and for the image as well. And then we can also do it for the button. So let's do, let's set the test ID to card generation button then lastly for the card image. Output and then also for the title and description. So card title output and card description output. So with all of these new test ID attributes, I can repeat the code generation exercise we did before. So let me actually start again our application in preview test model and then run the playwright code generation tool. And in this case we can assert things and as you can immediately see playwright now it's smart enough to actually prioritize the test IDs and select them by this get test ID utility. Yeah I won't go into details on the whole flow but as you can see in this way we end up with a more stable test so that in the future if you make changes it's much more difficult to actually break these tests unintentionally. And so yes this concludes the fifth exercise and this brings us to pretty much the end of the workshop. After the workshop if you are interested in exploring a bit more and keep playing a bit with the application we put a couple of ideas in this extra and in the repository. So there are things you can still work on if you want to get a feeling of the more on the Calculator platform and what it offers. Please if you would we have this Google form so we would love to hear some feedback and what we did right, what we did wrong and whatever you can, whatever feedback you have for us for improving the future. Yeah and I pasted all those links so feel free to check everything out. Write any feedback as well as for future reference if you want to access the recording I pasted that link in and the repo and the slides are all there and if you all have any questions we'll just hang around here for a couple of minutes. But otherwise that's pretty much it. And by the way yeah obviously thanks so so very much for joining and yeah. Sticking through the whole workshop because it is a three hour workshop. Yeah actually it has to be the last one but with this. Thanks for attending Dan, thank you. Thanks very much. Thank you all. All right, see y'all. See you, thank you.