Living on the Edge

I look forward to disappointing everybody here. It has been a while. It has been two years since I have been up on the stage. My name is Sunil Pai, I work at Cloudflare on the workers team. I used to be on the React team. They got rid of me pretty quickly.

And we have React stuff to talk about, but before I do that, I do want to start by saying I've missed you all so much. This is so weird. I met a bunch of people at the speaker's dinner yesterday. It's nice swapping stories, doing the same awkward hugs. There's the bro hug, there's the 200 hug, there's the fist bump, there's the weird elbow thing and I think it's time to retire that. But things have changed for me. As you can see, I get way better haircuts now. I dress a little nicer and especially for the occasion, shout out to Tom Dale. I hope I'm doing you proud. I've been eating better, exercising better, but the thing that I am most proud of and I'm sharing it with all my personal friends here is two days ago, I finished 500 days smoke-free. I quit smoking. Which is a good thing. So happy. I'm very proud of it. This is the thing that I've been telling everyone. It does leave me with one complication. This has been my GitHub avatar for the last 10 years. Ever since I've had one. It's cool. I used Photoshop back in the day when I had a pirated copy. But it doesn't really represent me anymore. But a friend of mine did suggest a minor modification and I will be uploading it later today. I think it's pretty good. This was actually made by Siddharth Kshetrapal. He's not here today because his visa got screwed. It sucks, but look forward to his talk. But I think that's a good modification. And that's my story so far. Cool.

Let's get to the talk. Three things you should know about the talk I'm doing right now. It's kind of boring. We'll be talking about a couple of APIs, but if all goes well, you probably won't have to use it. Things will just happen. And that's nice. That's kind of a nice thing about React. Like all the improvements are slightly incremental. Nobody has to do any massive rewrites. You can leave old code as it is. This talk is a beta talk. Much like the actual APIs and the fact that React 18 is on the horizon, but there's going to be about a year, two years of experimentation usually when these things come out. Much like that, this talk itself is also in beta. This is the first time that I've put it together, what we're talking about, and it also means that maybe over the next year, I'll be improving the talk. So if you spot any mistakes, sorry about that, but it will get better. But this talk itself is in beta. The talk is also about the future. I don't usually do API talks, I like talking about the work I've done, but this, I think, is exciting enough that it's part of the React release that no one is really noticing. Everyone is talking about the cool hotness, which is server components and concurrent and all that, but I feel like this actually is way more defining for all the things we're going to be doing in the future. So those are the three things.

Let's jump straight into it. Standard interview question for all web developers, right? How does the Internet work? When they ask you that question, really the question is, hey, let's say you type in ReactAdvanced.com into your browser. What happens? And there are a number of ways to talk about it. You can go into it in a lot of detail, you can talk about it at a broader level. I'm going to be talking about it as a conversation between a browser and the actual website.

Let's dive into it. This is an Internet Explorer. So the E stands for Internet, a classic. That's the only browser I've known. And it's talking to UGLE.com. Convenient that they're both an E, I think. And you ask it a question. What can you tell me about the Amazon rain forest? You type in Amazon rain forest in search. And search engine says OK, hold up. I got you. I'll let you know. And it goes back to its services, and it says hey, team, all y'all, what do we have for pi that we can tell him about the Amazon rain forest? So maybe there's a photos team that says OK, here are all these photos I have about the Amazon rain forest. Take this. The search engine is like, OK, cool. That's fine. That works. There's a flight service. Imagine that, a search engine giving you flight tickets. I think that would be a killer service. Nobody else is doing it, of course. And it says hey, maybe pi would like to fly to the Amazon rain forest this weekend. Here are tickets. Of course, I think it starts in December. It's going to be a little while away, but here are tickets further. There's news about the Amazon rain forest, because it's not in a great state right now. It's being burned to the ground and being raised. And there's news about it if you want to read it and get more depressed about the state of the world. But, of course, there's a little video service as well. And it says, hey, here are some videos. If you would like a seven-hour stream of just lush greenery, we got that, too. Awesome. So then the search engine comes back and says, okay, I got stuff for you. Here it is. Let me present it to you. I forgot. I forgot there are going to be eight ads before you get to any of the content. It says, okay, fine. Here are a bunch of ads. Possibly from another site that sounds like the Amazon rain forest. And here's a bunch of content. Not bad. So this is how it works. You start a conversation with a server. It gets a bunch of data. Presents it in HTML as a website.

So if we had to implement this in React as a React component, what would it look like? Well, you make a component. Let's call it an app component. You can see the code. It's fine. You can see the slides later. You'll make an app component. Which has a header, a footer, and you'll write five components for your ads, images, videos, news, flights, which takes a bunch of data and renders it. You'll pass it into something. So you'll fetch the data before you render the component. You're like, hey, give me all the ads for Amazon rainforest, give me the images and videos. Get all of it, and then render to string. This is what happens on the server. Usually a metaframework like an ExJS takes care of this, but you say get the data and render it into it. Sure? Okay. This is how it works. It's not great. There are some tradeoffs with this model that you might have noticed. One is that you can't really co-locate the requests, say, get data with the actual component that asks for it, particularly on the server. You could probably do this on the client side, but on the server, because it's a one shot thing, you can't put them together, you've got to get all the data first and render it, or you have to do, like, other stuff. It blocks the whole page on the data. Can you imagine, like, you won't be able to see any of the photos until all the videos have also been fetched, or if one of them is slower, the other ones are blocked. It needs to get all the data before it actually renders it done. Which is why you end up doing hacks, right? Like, it's great, there's a whole ecosystem of frameworks out there that your ExJS or and fetching libraries like Apollo and Relay and a whole bunch of GraphQL stuff. But let's admit to ourselves, like, it is kind of hacky that you have to build something separate that's not inside React itself to do these things. In the beginning, it was fine because it involved experimentation, but now you have to stitch up a whole thing and use a meta framework to do it. It's just a little ew. Like, it's not perfect. Right? Like, you feel a little uncomfortable with the situation. You always have to make trade-offs. Do you do all your compilation when you build the page? What if it's a site with a hundred thousand pages? Do you have to do it dynamically? It's kind of weird. But this is the state in 2021. It's kind of fine. I mean, many multi-million dollar startups and companies have been made around this API and other things, of course. Of course, it's the website that got you the money. I don't think we should be fine with this. We can do better. This is a community that is built on experimentation and innovation. So let's take a little bit of a... Let's keep that aside for a minute and talk about a feature that the internet has. It's an idea called streaming. The idea is that you should be able to send data down as soon as it's ready, even before you have everything else. I don't want to get into too many technical details about it. you can Google chunk transfer encoding for HTTP 1.1 and there's something else for HTTP 2. There's a whole bunch of specs. I'll try to explain it as simply as I can. So let's take the same website and turn it on the side. Imagine coming from that side to that side. No. Yeah. That side to that side.

Right? In your one shot method, you would send it all in one go, but in the streaming method, you would stretch it out like chewing gum and send out the bits as soon as they come. You would be able to send a header immediately, then the ads as soon as they're ready, and then the photos, flights, news, videos, and then finally the footer. What would it look like as a user when you start loading the site? You would start off with the header, wait a bit, and then the ads pop in, wait a little more, and photos pop in and the flights and news and the videos and then the footer. That's better. At the very least, you're not blocking, like, just the header being loaded, waiting for stuff like content to load, which is fine. And to be fair, I think Google actually does do streaming. But we can't really do this in React land so far, of course, because it's still a one shot. We can do better. Anyone who knows me knows that this is my mantra. The nice thing about being a UX engineer is that there's no upper boundary on how good you can make user experience, right? You can just keep making it better and better. Anyway. So that was streaming. So let's keep that idea to the side. This is a React conference, after all.

A couple of years ago, there was an experimental feature that was launched at React Conf 2019. Holy shit, that's two years ago. That's a while. Anyway. They announced a feature called suspense. You can mark components as React.lazy and it would load it asynchronously and use suspense to mark a spinner. There's also data fetching. The problem is that never really worked with rendering to string and server rendering. Some people use it for client-side apps, and it's nice. It's a good model. So we'll just quickly dive into it and see what it looks like.

In this model, for the same page flow that we just discussed, you would have, let's say, an ads component that fetches some data inside it and then renders that data. A quick thing to note is that there's a bit of a glitch in the matrix. Notice that there's no await statement, and the way React does this is kind of funky. If you're interested in diving into the details, it throws a promise. It doesn't matter to a developer as you're using it. You just write it like a synchronous code, and you can use it. By the way, I've been using GitHub co-pilot, and I did this and after this, I wrote function all the code for me. You all have been using it? It's kind of scary. It's AI for your code. It fills in your code. Anyway, so you would also have an images component that just takes the search term, figures out what images are there for it, and like spits out the HTML that, well, the DOM tree that would work for it. Similarly for videos and for the ads and so on. And then what you would do is you would revisit your app component and you would wrap all of this with a suspense component and you would give it a fallback. Say a spinner. And the nice thing about the experience for this, when it's a client side app, is that you will have a spinner that waits for all the data to load and then finally renders it. So the experience would be, hey, you would render a header and a footer and a big spinny spinner in the middle. I should choose a better one. It's fine for now. I'll ship it. So it waits for it. Waits for the data and as soon as that's done, it renders the content. That's not bad. But we can do even better. That's the mantra for today, right? Let's say that you can also mark each of the components with a suspense boundary. And let's say for the sake of discussion, each of them have the same spinner. You wrap all of them up. And then the loading experience for it is, hey, it starts off with five spinners. Maybe the flights load first. Not bad. Then after that, maybe the ads load. Then maybe close to each other, the news and the videos load. And then right after that, the photos load. That's not bad, too. At least it doesn't wait for everything. As content comes in, it renders. Still not great. You want to load it at least in order, even if the data resolves. We can do better. One of my favorite components, a component called suspense list.

Now, mark that out with the green. You can see the code later. But you can actually group together suspense components. And you can say, hey, reveal these as in a forward order. You can also make it backwards. You can make it all together. It's a lot of fun. Feel free to try it out.

Anyway, you can say, hey, make sure that the ads load first. At least they render first, even if the data for the others loads later. Just so we're clear, the data for all of them is happening at the same time. Make sure the first one is rendered. And then I group the other four and set another suspense list. Nested suspense list. That's cool. And say that I want those forwards as well. Okay. So what does the experience for that look like? Again, we start off with about five spinners. There might be data so the ads load in. Some content might have actually loaded for the others, but we have marked that it needs to load in this order. The photos load. And the next one loads really quickly, so your flights and news and the videos load. That's a much better user experience.

But the problem of course here is that this is now a fully client-side rendered app, right? So we have these two tradeoffs. One, we can either generate all the HTML on the server side but you have this janky programming model and you have to make sure you have hacks or a whole bunch of optimizations. That doesn't really gel well with the React model. Or you can do it completely client-side and have ostensibly a better user experience once all the JavaScript loads but load performance is worse. It takes a long time for the JavaScript to load and then the requests have to go from the browser. So you got to do one or the other. Right? The mantra. We can do better.

So this is the one API that I've been talking about. It takes render to string, which we've been using for the last five years and it's been fine. And it replaces it with render to readable stream. So we can now do streaming rendering with React. I just want to recap how good this is. All right? So let's just recap. So we're gonna look at the same thing we looked at right before this. Traditional streaming looks like this. It stretches it out like chewing gum or a rubber band, I guess, whatever. And starts loading things one after the other. So the header would load. Then the ads would load. Photos. And like all these blank spaces. Which is fine. But it's loading. Right? And videos and the footer. So this is what we could get if we had used traditional streaming. Which we can't, just so we're clear.

And possibly how Google already does it. But with render to readable stream. You can start off with the spinners. Wait a little bit. The ads load. The photos. The flights. The news. The videos. And here's the kicker. That entire experience happens before any of your JavaScript loads. This entire experience is happening down the HTML. You can have a superior user experience without JavaScript on your page.

So how does it actually do this? It's kind of cool. I have one slide to show you this, but really you should dive into it after this talk. So what it does is it sends that shell ahead. And it knows that because that's the component model that we've done. But as soon as the page is over, it starts sneaking in little hidden divs with the content inside it. It's not fancy as it is. It's quite a hack. And as soon as each of these bits load in, it's like one line of JavaScript. One function call that just says, hey, take this div and replace the spinner with this content. There's no React on the page, nothing. You can even remove it and you still get the same experience. So that's pretty dope, I think. And this is pretty fundamental to the rest of the React. So... Innovation that we'll probably see over the next year. Server components, the new hotness built on this tech. Any ideas that you have for new CSS and JS libraries, because it's been a while since we've had a new one. Might as well make 12 more over the next year. You might want to make sure that it works well with the streaming rendering model. You could... Data fetching now becomes way more interesting, right? Now, instead of, like, the hydration step being one blob of data that you just inject in there, and you can do it piece by piece if you want. Lots of fun stuff.

Anyway, so just to recap. So the new server features that we have, once you replace render to string with just one line, which is render to readable stream, suspense just works. This is a huge deal. It's not worked for the last two years, which is why a lot of people haven't even used it in React apps, but now, it just works. React.lazy, all that. You get to do loading patterns, again, without your JavaScript bundle on the page, just works. Like, you can use suspense list and suspense boundaries. Very cool. This is my favorite thing. The spinners work, actually, without the JavaScript bundle on the page and in an order that you can decide. Which is honestly I feel like all frameworks should steal this idea. And, of course, they steal from React all the time and say... Oh, we're already better. You ship before React does, which is like... Do you see why they didn't want me on the team anymore? But then there's like a bonus feature.

And I actually didn't include it in here because I didn't think I would have time. So the page can actually start racing your JavaScript bundle with the server streaming. So in the beginning, when you start up, it starts streaming down all these server... All this HTML. But you can also start loading the JavaScript. Usually the first time you're visiting the page, the JavaScript bundle might take a little longer to load. But the second time you visit the page, it's cached. Which means the JavaScript bundle loads immediately. At this point, React tells the page, this is not a server rendered page anymore, it's now a client side app. And immediately takes over so it can load even faster than the server rendered page. Wild feature. Just love it. So it can actually raise client and server side very cool. So these are all cool features. But there are tradeoffs. That's the other thing I say. None of this is actually free. What you need to do now is you need to run your own server. Some of you might have been using something like a create React app or something that was client side only. But if you want these performance benefits and a better programming model, just happy you're users, really, you now need to invest into a server. So you have two major choices to do this. One is Node.JS. Love Node. It took me from a toy JavaScript UX developer and made me effectively a full stack developer. Love it. Didn't have to change much. Just plain JavaScript. Shout out to stuff. It was a pretty great day, about ten years ago. But what you do is you either like have to rent hardware, a VPS or one of those things with a host like Heroku, Distill Ocean, I don't know, I haven't done it in years. I assume there are others on the market. Relax, it's just a dry cough. I'm fine. Yeah. So you pick one of these machines, and you then have to, like, set it up. You have to, like, set up process monitors, like, the moment it dies, you need to do a restart and monitoring. It's fine, I guess. I'm excited about stuff like fly.io. I know it tries to give you heavy metal on the edge, fix a bunch of cities and you can pick it and deploy your code onto it. Shout out to Ken, he deployed his site onto it, and it's a really fast, really great service. They're doing some very cool stuff. They seem to have hired a bunch of interesting people. But it still isn't trivial trivial. Like, you still kind of have to deal with your server. Or you do what's called serverless computing. Right? Which is your AWS Lambda or Vercel. Which is fine. But the problem is that they don't actually support streaming. The API ostensibly does. But what it does is kind of buffers it and only once it's done does it send the content down the pipe.

Which kind of ruins the effect that you want. You want it to load early. That's choice one. That's choice one. You can do that today. I bet some of you have your stuff up on node. It's not a bad choice. Also node isn't really built for the Lambda use case. Which is the suicide use case. It takes something like 200ms. Last I checked. I could be wrong about these numbers. It takes 100 to 200 milliseconds just to startup. You can look for a cold start time and you'll see people talking about it, I guess.

The choice too is this new breed of serverless computing that's happening across the world. My employer has something called workers. Fastly has something called edge compute. If anyone has used it, let me know. It's hard to use it right now, but I hear great things about it. The new kid on the block is demo. They have something called demo deploy. Shopify has something interesting. They have their own framework for deploying Shopify components. And I think someone speaking about it later in the conference. I'm super looking forward to it. Very exciting work. Gatsby I think now runs. Gatsby used to be a static site generator, but they're not so much, but they're not openly admitting it, and they run something called Gatsby Cloud. It's cool, by the way. It's called DST. I think Siddhartha is here. He'll be talking about it later. And there are more. There are going to be more. There will be a lot more people who will be... I expect more people to try this out. And there are some usual patterns. I would like to talk about CloudFlare workers. I picked them. Pay me for this. It's kind of nice. So CloudFlare workers. It's a standard-based runtime. You can do stuff like fetch, regular request response, a whole bunch of web standard APIs. No DOM APIs, but you don't need that on the server side. You have React there, of course. Which is nice. The code is super simple. You don't have to spin up and say a port. No.

You just export a function called fetch that responds to a request and returns a response. Super nice. It's across 250 cities across the world. 250 cities, like it's a small number and a big number. It's the biggest network I think right now. And they have deals with something like 10,000 partners or some shit like that. The employees aren't told where in the cities the actual data center is, by the way. So we like joking amongst ourselves that it's either underneath the tube, or it's in the air traffic tower in Heathrow. Because that's where you get best reception. It's either that or the BT tower. We're not sure. But massive network across the world. And the numbers are kind of wild. Because they have such a great network, they're within about 20 milliseconds of 80% of the connected world. And within 50 milliseconds of 95% of the like internet connected world. And to show you how fast that is, I want you all to try something with me. Okay? All right? I want you to blink as fast as you can. Okay? And we'll see how fast you can do it per second. Okay, ready? I'm like the blinking meme dude, right? Anyway. So I can do about 3 to 5 times a second. But Cloudflare can do about 10 to 50 requests in the same amount of time. Which means if you actually write your site well, you can load your whole website in like a second, maybe two. It's really fast. It's like scary how fast it is. And what I really like about stuff like Workers and the other runtimes is that they all have like zero startup time. There's none of this cold startup time or anything like that. It just starts up. You can start it, React starts up, take some data, throw it down the thing. But it's not just good enough to have a runtime that runs your JavaScript. You also need some kind of persistence. Because we have JavaScript here, but your database is halfway across the world, still not great. So, Workers also provides a little key value store, which is just hey, for this key, store this data. You can fetch it where you want. Which is also replicated across the entire network, which means the runtime and the data is, well, on the top of BDTar. And we also have this sci-fi thing called durable objects, which is just the coolest thing I've heard of. They're literally JavaScript objects that can move from data center to data center, depending on who's asking for it. It's wild. What that means is, let's say I... And you can use it for, like, WebSockets and synchronization and stuff. Which means that, let's say I'm talking to a friend in, let's say, San Francisco. I don't know anything about American geography. But let's say that New York is between London and San Francisco. Maybe. Let's say. Somewhere midway. Probably somewhere in the... I don't know. So the durable object that we use to, like, establish a WebSocket connection between each other could potentially, like, migrate to New York so that we get the best data to talk amongst each other. And then let's say a third person joins us from China, in which case, like, maybe the object figures are the centroid of these three locations. It's all very sci-fi.

This is, like, we're trying to figure out what the database story around it here is. But it's a very novel invention and we're dying to see what people build with it. And there's so much more.

And when I say so much more, I mean Cloudflare has a deep portfolio of services, and you should totally go check it out. There are also so many cool things we are building that I'm not allowed to tell you yet. And what you can do is buy me a beer right after the conference and start talking a little bit. But I can't do it on screen! Hey, boss manager! Anyway. Anyway.

So you can go explore more at workers.Cloudflare.com. There's a startup, a CLI you use, and you can start writing JavaScript and it works. It will be getting better soon. But the vision really for workers and I assume all these other run times, right, is I want to stop calling it serverless. What I really like to imagine it as is like it's one server that envelopes the world like a buckyball with your database all surrounded. Anyone taking a photo of this? I look like a maniac, I'm sure. So you can envelop the entire world in this mesh. Right now it's 250 cities. It could be thousands in the future. We might give you some hardware that you can just chuck behind your washing machine and then you can FTP into it and set your website up just like the 90s. It would be great. So edge networks like this are such a good fit for the React streaming model. It's instantaneous. We can give experiences that are way better than anyone's had in the past 30 years. The web is getting old.

So, while there is going to be an incremental story where we improve all these things, what I really think is going to happen is that this is a big reset moment for React. Of course all the popular libraries will still work with the existing model. The team itself is collaborating with CSS and JS library authors, and library authors. They work well. But I think there's potential for us to do more. For example, Node doesn't run on these networks, which means Next.js doesn't run on it. I don't know. Next.js, the folks might make some changes there. But it sure would be nice if we started exploring. If we had to build something from scratch, streaming as a model. data fetching, way more lightweight libraries, and the ability to talk to APIs, like durable objects and KB stores. What could we do? I want to leave you on that note. I want you to start thinking about what this means for React on the ecosystem. A lot of the complaints about React have been, like, bigger bundles, and over-engineering, and JavaScript fatigue. But maybe this is a moment for us to start removing the fatigue, to, like, simplifying removing the parts that we have needed just to be able to have a competent stack. And maybe we could have, like, a different story. I don't know. I'm going to try. I expect everyone else to because I don't usually ship my libraries anymore. But there are folks out there who will look at me and be like I find challenge accepted. And I totally would like to see that. There's some links. Well, you can just literally Google React18 working group and you can find a bunch of details about what I was talking about today, how to upgrade to the new API, guides for library authors for how to upgrade their authors, how you could possibly build a new JavaScript runtime if the next big serverless entrepreneur is in the crowd here somewhere or watching this in the future. There's a whole list of like... Sebastian from the team wrote down a list of things you can do to make it better. And yeah. I look forward to it.

I'm super excited about this very simple API that I don't expect many people to use by hand but I expect will redefine the experience for React in the future.

My name is Sunil. You can find me 3.1 on Twitter, which is the worst thing to spell out to somebody on the phone when you want to tell them what your email address is. Yes, it's 3.1, all words, no numbers, no dots. You can reach out to me there. I'm happy to talk to you after this. And I'm looking forward to talking to all of you at the conference and grabbing a beer after this. Thank you so much. Thank you. Thank you so much, Sunil. Would you step into the Q&A lair? Oh, you don't even need to bring your own water here. We have water at the Q&A lair. It's quite a special place.

Hey! How are you? How are you? I'm good. How are you? Not bad. Thanks for a wonderful talk, as always.

I am a K-beam user. I am a K-beam user. I do all the stuff. I am a K-beam user. I do all the stuff.

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a globe K-beam user. I'm a globe K-beam user. I'm a global K-beam user. I'm a K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.

I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user. I'm a global K-beam user.