Developer Week Day 3: Realtime & Observability

What's up everybody. I am Ricky. I lead up DevRel here at Cloudflare. If you watched on Monday, you saw me there. I'm back for day three of Developer Week. I am so stoked about what we're going to be talking about today. Two of my favorite announcements of the week, observability and real-time kit. We're going to kick off talking about observability. And I'm going to bring up Rohin. This is your first time on a stream. So do you mind introducing yourself, telling folks how you ended up here at Cloudflare? Yeah, I'm so excited to be here. I'm a product manager. I work on the workers observability team, just generally under the workers umbrella. Yeah, I've been at Cloudflare. I'm actually a boomerang at Cloudflare. So I was at Cloudflare a while back as an engineer. I just joined a year ago to come back as a product manager on the developer platform. I love the boomerang stories. It's rad to have you back. And can you tell us a little bit about the announcement and workers observability? Of course. Yeah. So workers observability, generally when you write workers and when you deploy your workers, you need tools to be able to capture the logs to understand what's going right or what's going wrong in your application. And traditionally, we've made this a little difficult for you. We've given you something called real-time logs to be able to stream logs directly from your application to your machine. But if you wanted to actually save and persist those logs and access them, analyze them later, we make it a little challenging. We require you to send it to a third party. A lot of people asked us, how can you just do it natively in the Cloudflare dashboard? So we did launch something last September called workers logs. So we gave you access. I'll show you in a bit. But gave you access to all your logs for a single worker. But then people who are building more complex applications with more systems involved were asking, why can't I just look across multiple workers? Why can't I answer custom questions? And so that got us thinking. And so that led us to the announcement of the observability tab, a unified tab where you can go look at all the metrics, all the logs for all your workers in a single place. And we also built out a query builder. So a way for you to construct structured queries to ask any question you want, answer any question you want. I love it. And this is a little inside baseball on Cloudflare, but every week before developer week, we do a briefing with our core community champions and MVPs. And I love telling them about the observability updates because every time we talk about observability, there's so much excitement. And then there's a list of like 20 other things people want next, which I think is a good sign of what's ahead for you, though I'm sure prioritization is always tricky in your role. All right. How is this different than something like tail workers or log push? Yeah, of course. So I generally like going back to like the export mechanism. So Cloudflare, you know, you can build applications on Cloudflare, but you may have your own observability provided that you already prefer for different reasons. Right. So we do want to play really well into that ecosystem. We want you to be able to send logs wherever you want. And I think those are products that we're continuing, we're continuously investing in and improving. Log push is basically a mechanism to batch many log events together and export them as a batch to a provider. And we'll have some integrations with larger observability providers. There's also tail workers where tail workers allows you to actually do more custom transformations. So the way you can think about a tail worker is a tail worker consumes all the log events from a producer worker, from the core, like your core worker that is producing all the log events. And so with tail workers, people use it for all sorts of interesting things. But, you know, I thought a really good example is let's say you're trying to surface some of these logs. Let's say you're building an application, a product where developers can write code on your own platform. Right. We have a great product called Workers for Platforms that allow customers to write code in a very secure and sandbox way. And so tail workers allows you to like is basically a way that you could do a transformation and only export the logs that you want to your provider, right, to a third party. So think about tail workers as you're writing code to transform your telemetry data before sending it to a third party. Yeah, nice. And all right. I kind of I have more questions, but I know you have a demo. I kind of want to jump into the demo and talk through some of these other questions as you're showing us what's new. Does that work for you? Yeah, absolutely. Let's do it. Let me share my screen. So. You want me to start off with the new stuff? Yeah, let's show the new stuff first. Great. Let's do it. Okay. So. Now what you'll find is on the left hand side, we under workers and pages, we have an observability tab that we're launching. And here you can see, you know, you can filter by time. You can see just a high level number of events across all your workers, all the errors across all your workers, CPU time. And you can see all of the events. You can group these, what we call events is just, this is the this is a raw log event. Right. But raw log events can be grouped into what we call invocation. So an example of an invocation is like a fetch request, right? You make a fetch request that's going to invoke your worker. You might log five times in your worker. And so that's a single invocation, right? So if I click on one of these, you'll see, okay, look, this one looks like it was saying attempting to authenticate. The job was validated and authentication was successful. So that's, you know, that's really helpful for me as I start to debug. Yeah. And I can expand on, some of these fields and actually really gather more rich metadata. So this is the overview page, but I think what we're really going to get at the meat of this is the investigate tab, right? So the investigate tab, this is the query builder. And I think what's really cool is like just being able to ask any question, kind of hinted at. Do you have a question you want to answer? Should I just try to maybe come up with something like, you know, something I thought is fun is trying to look at the request path and like the status codes and just trying to understand latency for those. Like, does that sound interesting? Yeah. Yeah. I was going to say, I'm like doing this with, you know, Wrangler tail all the time of like trying to like watch live. So yeah, that's figuring out latency on requests and seeing the statuses along the way is super interesting. Yeah. Okay. Let's do it. So, so let's, maybe what we can do is, you know, okay, we can do the last hour, but why don't we just add a filter here? And I'll add a filter for status. So, or maybe I'll do path, actually. I'll start with path. So this is going to show you, that's actually not what I intended. I want it to group by path. And so let us group by path. And so you'll see like a few different fields, right? You'll see that there's a visualization field at the top. You can add all sorts of visualizations. So maybe you want to do like a sum, a P90, a P50. Here in this case, I'm just really interested in the number of events that are happening. I can apply different filters. So we can go through the filters in just a second, as well as just the standard textual search. What, I think what's fun here is the group by, right? So now what I'm doing here is grouping logs based on path, as well as based on the script itself. So you can look, you can see that there are kind of three paths for my worker. It looks like there's a fourth path. There's a separate worker that has a slash path as well. And so what I can do is let's go back. Maybe we can do, you know, 12 hours. Let's see how the traffic patterns look to do these different paths. Okay. So it looks like, you know, this multiple logs worker has really taken off. Maybe, you know, it's a little noisy. I'm really curious what else has been happening. So I'm just going to filter it out, right? And you'll see that the filter out happens here. Okay. Now, all of a sudden I see so many other requests to other workers that I'm interested in. Maybe what we can do is we can also just add like a visualization on like the P50 or maybe P90, P90 wall time. I think that could be interesting. So wall time is this concept of how long does it take, how long is your worker alive? And that includes waiting for IO time. We can also look at CPU time, which is the amount of time that your worker is actually executing code. So now you can kind of see, okay, wow, you know, this wispy wildflower worker in the root path has had five events, but each request is taking almost 3.6 seconds. Yeah. What's going on in that worker? Yeah. Well, I'm actually curious also, like, what is the, maybe we can just add a filter for this one, for this specific worker. And we can also look at CPU time. I'm really curious what the CPU time is. I'm not sure what's going on, honestly. So let's see. CPU time. That's how you know it's a live demo is now we're just actually trying to figure out ourselves what's happening. Yeah, exactly. So it does look like it's doing some work here. 79 milliseconds CPU is, so it is like, you know, this is a relatively busy path. Maybe what I can also do is add a filter here. So now I filtered and this is, I guess, redundant, the multiple logs. So let me remove this. So it looks like what I'm doing here is I'm just filtering now for the wispy wildflower at the root path, CPU time, wall time. Let's actually go into invocations and let's try to see what's happening. I'm not sure if actually this one has many logs for us to look at. Let me see. Okay, let's see. This is a live demo after all. So let's try just doing the script name here. Let's look at the invocations. Okay, so and I'm going to do the last 12 hours. Okay, great. So now I can kind of see all the logs. I'll actually go back and add that path. And let's do the root path. Here we go. Okay. So, okay. Yeah, it is kind of odd. Some of them are taking not that much time, six milliseconds, 11 milliseconds. Some of them taking a lot of time. So I'm not quite sure what's going on. I actually have no idea what's going on in this worker. Yeah. And it looks like, you know, this person, whoever built this worker is not, is actually not logging that much in the end. So it becomes slightly less interesting of a demo. Because, you know, a really nice feature that we've actually added in like this, like workers logs product and the workers observability product is what you're seeing here. It's called an invocation log. An invocation log is a structured, it's a structured log. Structured log has a lot of fields. You're basically logging JSON objects. Instead of logging, when developers normally log, they might write console.log and like a string. The problem with string is it's, there's a lot of like metadata in that string that you don't necessarily want, periods, and articles, right? Kind of want just the crux of what's interesting. So here in this phase, you can see, you know, potentially corporate proxy, false. Okay. Like that's metadata that I can then filter upon by just adding a filter right here, right? So we give you a structured log for every invocation, containing a ton of rich metadata on what's happening from Cloudflare's perspective. So it looks like this, this pretend, this landed at Colo JAX. The time zone was Chicago. It looks like I can see the user agent. It was a Palo Alto networks company and yeah, all sorts of interesting things that I can then, right? Oh, this is awesome. And so you said like typically you do a console log that that's what I do. I have like 50 console logs when I'm trying to debug something. So to get this, this setup with the nice JSON object, what, what does a developer do in their code? Oh, it's so easy. Let me, so let's go, let's go to a worker, right? And I'll go to, you know, multiple log. So there's two ways you can, you can go to settings and why don't we just turn, turn it off and turn it back on. So it looks like for this worker, it's already on. Yep. So, you know, we could also go to a worker and turn it on for the first time, but I'll, I'll turn it off in this case. And so, and that's it. And I'll deploy it and the dashboard, you know, we'll, we'll tell you if, if you use Wrangler generally, then we would recommend adding the Wrangler config. So, and that's the recommended path. So do what, do the happy path. So add it in Wrangler, add it in the dashboard, but to enable it just a single click, right? Quick deploy. If it's Wrangler, it's two lines just right. Enabled equals true. Amazing. I think what's really, what's really interesting here is like, yes, we're doing logs right now, but there's so much to come, right? There's so, there are pillars of observability. Like we, I'm going to leak a truth that everyone knows, but tracing is going to come. Yes. If you can instrument tracing without any instrumentation, right? You just press a button and then you start getting spans for all of your, for your applications. Yeah. And, and you stole my favorite question to ask, which is what can you leak? That's going to come next. So I love it. What, what, what is the thing with workers observability that you, you want to hear from developers about as they're getting their hands on this more? Like what, what's the feedback you're most interested in? Yeah, I'm really, so I'm really interested in just like seeing what you all are building, right? Like the types of queries here, is the query builder actually helping you? Are you, are you finding, are you breaking it in any case, right? Is it not helping you answer every question you have? If so, like absolutely want to hear about it. We want to fix that for you. I think there's lots of improvements we can make to this overview page as well. It's like, what's missing? I think this was, this was our first approach. We have a lot coming where we've been playing around with MCP. So maybe, maybe a lot of little MCP text box there too. But yeah, that would be really great too. I think, oh, I forgot to mention, you know, you can save these queries and you can, you can now share it with your entire team, start it locally for yourself, save it with your team. I think that's also cool features. So yeah, really I'd love to hear about that. And if they're general observability problems, then you can always, I'm always here, all ears on that. I think, I think the first thing that's going to come up after we launch this is why don't I have alerts? Why don't I have real-time errors, right? That's, that is the next logical question. So, so I think, yeah, please give me all the feedback. Love it. What about, so this great observability for workers now, are we going to start seeing that come to different parts of the developer platform, like durable objects? Yeah. So this actually works well with durable objects today. I think, I think you'll see some hiccups with durable objects, just the way our system works today. If you have like a long living durable object, potentially hours long, like the, all the logs are not emitted until after the execution, the durable object is complete. So we have some like really substantial platform level changes that are coming so that we can enable streaming logs. So as logs occur in the, in the, in the worker's runtime or in the durable object itself, they're immediately streamed out to the tail worker or the client, right? The consumer of said logs. So I think those are pretty substantial platform changes that we've been making a lot of progress on, and I hope we can start rolling them out in the, in the coming weeks. But yeah, that's, this, this works with anywhere you can write code today on Cloudflare. Ah, incredible. What, what, what have you wanted to talk about or show off that I haven't asked you about yet? I don't know. I think that was, that was pretty expansive. I think we can, I'll just double dip on workers logs for one second. We showed the query builder. I do think it's really helpful to show, you know, we've made a bunch of improvements on the invocations tab or on the, on the metrics tab. Metrics now, see metrics immediately, nearly immediately after you launch your worker. And if you go to your logs tab, right, I think this is, if I just go to events, that might be a good example. Like there's a bunch of improvements that we've made here. I think what you'll like a lot is the fact that, you know, you can now add fields. So let's say I want to add the error field potentially. Now I've added it here. So you, it looks like there's no errors, so that's pretty much. Yeah. So I think, I think you'll find these views to be extremely helpful. I hope the, I hope that you do. And I think the other thing that people have asked were like, you know, events is the number of events in a specific view. Like if I just like zoom in the only, okay. 840 events in this, in this window. So we're, we're announcing that workers logs is GA today as well. We've, we've made it stable as a product. You should see no performance implication on your work this by turning it on. And we've added a set of features that I think gets us to a point where we can keep iterating. I think we also have the public API. So we want to see what you build with our API. I love it. I also, this is, this is so silly, but the like little like click and drag to zoom in felt like the future where if I were in VR, I would just be like swimming through my data. So that's a very slick little UI moment. Yeah, I love it. It's, it's great. I think it'll be, it'll be cool when we, when we do, if we ever get into like traces, for example, with we might represent traces as dots and then, you know, instead of your X axis or your X axis right now, the X axis changes, but the Y axis is bound. What if you just random areas throughout the, throughout the crack. Oh my gosh. So good. I'm going to definitely be in, in the dashboard with my Apple vision pro now, just seeing what, what I can do. Yeah. Yeah. All right. What, what about where can people find you? You talked about feedback and wanting to hear what people think. How, how should people tell you about their experience with all this? Yeah. I think you can, you can always DM me on Twitter if that's your preferred medium. I'm at rohanlohe, L O H E. And you can also email me just rohan at cloudflow .com. I'm all ears. Send me all your feedback. We also have a pretty active discord community. So if you join if you join discord, we have a workers observability channel. And so if you, I think that's a great place to like lead feedback, crowdsource ideas, see how other people are solving their problems. Well, thank you, Rohan. So, so rad stoked. It's getting in everybody's hands. I hope you enjoy the rest of your day. And I think we're going to be hanging out all over London too. So excited for that. Yeah, me too. Thanks Ricky. And happy developer week. Happy developer week. All right. Let's go from observability to another one of the announcements that I'm super stoked about this week. Real time kit before we get too deep into it. We have Zedd and Abhishek here. Zedd, do you want to introduce yourself first? Yeah. So my name is Zedd Faruqi. I'm a lead product for media products at Cloudflare. That includes products like stream, images, and calls, which is now known as real time, which we're going to talk a lot more about in the next half hour. Awesome. Abhishek, what about you? Give folks your story. Yeah, thanks Ricky. So hi, I'm Abhishek. I am one of the co-founders and CEO of a company called and we've recently joined Cloudflare and we'll basically become real time kit with the calls team together. So excited. Welcome to the crew. And Zedd, you teased out my first question. I want to hear the story of kind of how we got from where we started with calls and our media work in general to where we are today with real time kit. Yeah. So, you know, I think when we build products at Cloudflare, we have two, if you zoom out, two dimensions that tend to influence a lot of our new product announcement. One is what are things that we are exceptionally good at that, you know, that, that if we, we just have to have certain pieces that if we build on top of the, the end result is something much better than what might be available. The second is how do we take something that is very complicated and simplify? I think that those are the two themes that you will probably find across Cloudflare products. At least one or the other and almost every major product that we've, we've, we've shipped as a company. Now, a couple years ago, when we were thinking about WebRTC, we were like, what are, what is Cloudflare uniquely good at, right? We are known for our network, a network that is extremely low latency. We talk so much about it that, you know, we almost don't value it enough, I think, because we just talk about it being low latency all the time. But when it comes specifically to real time, latency really matters, right? I tell people that if an image takes an extra 200 milliseconds, 300 milliseconds, no one notices. If there is an extra 200 milliseconds, 300 milliseconds of latency on a, on a Zoom call that you're on, it will throw off the entire meeting, right? So I think that that is a mental model shift that a lot of people who don't spend their time in the real time space ever think about. So we realized we have the network. How do we build something very narrow that ships a lot of value? So we built a product called Cloudflare Calls, and it's essentially an SFU, which means that all of the WebRTC traffic can be routed through Cloudflare, giving you the advantage of, of not, of enjoying all the upside of WebRTC as a protocol without the, the, some really critical downside, which is if it's true peer-to-peer, whoever has the worst Internet connection tends to bring down everyone else's experience. Now, here's the thing, WebRTC is really complicated. So what we shipped was a building block, a low-level building block. So again, it took advantage of the infrastructure that we have, but it didn't do a whole lot in terms of simplifying building and shipping real-time apps. So, you know, it, it really helped us take advantage of something that we're really good at with, with the network. But I think our customers generally want to ship fast. Yes, they want a great network, and those are just prerequisites. But the, the whole shipping fast bit, you did not get just from an SFU that we ship with calls. Yeah. I, I, and I, I think WebRTC is one of those funny things, at least for me as a developer, because like the first time I started using it, you see the code samples. They were like, ah, that's some JavaScript. They're like, how, how hard can it be? I think is the trap we all fall into with WebRTC at first. And then you start really using it. You're like, oh, it's more than just like a handful of lines of JavaScript. Can you talk a little bit of like real-time kit, how it plays into you may making all that easier beyond kind of just, hey, it's, you know, cleaner JavaScript for you. Yeah. So, so what real -time kit does is it, there are two areas that are really challenging when you start building a real-time audio video app. I think you summarize it really well. Most of us go into it thinking how hard could it be, right? Because we have tackled other technologies in the past that seem more challenging than when you start building it for, you know, like, well, like, you know, I got a lot farther in the weekend that I thought I would. The thing with WebRTC, it's kind of different. It's hard to, you know, there aren't very many examples that we can compare it to, but essentially it requires engineering on the client side, on the server side, along with, you know, cross-platform. So Safari versus, you know, Chrome, Mac versus Windows, like each one of those things add additional complexity, right? So, so I think device management and WebRTC as a protocol are two areas where the SDK, that's part of real-time kit and, you know, the core piece of it adds a lot of value. Just to add to that, Ricky, like, I think you mentioned that, hey, you know, how hard is it to build with WebRTC? So for most people who are trying to build, you know, real-time apps today, they're actually, you know, if you look at it, web or mobile developers, they're not WebRTC engineers and you shouldn't need to be a WebRTC engineer to be able to build with the technology, right? So the real-time kit actually simplifies that, where it makes sure that it abstracts all of the WebRTC complexities, even on the client side, and, you know, gives you a very straightforward, easy to use SDK out in JavaScript, or, you know, if you're using mobile, one of the frameworks, right? So that's kind of the goal with real-time kit to make sure that it's really easy for you to get started with it. And then, you know, because it's running on top of Cloudflare calls, which is Cloudflare's own SFU, it also gives you access to this really robust and, you know, scaled infrastructure that probably no one else can access today. Yeah, that's a great framing. And I heard y'all may have some stuff to show off. Do you want to do a little bit of a demo here? Yep, absolutely. Right. So again, we are still going to be releasing this completely, access to people. But what I'm going to walk you through is a very simple way of how you can get started with real-time kit today. So what I have open is the real -time kit documentation. And as you can see, this is with a UI kit as well. We have a layered approach, which means you have a core SDK, you know, which is plain vanilla JavaScript or one of the mobile frameworks, if you're using that. And on top of that, we have UI kits, which are full-fledged UI components built specifically for use cases that the kit would solve, right? Majority of them being video calls and then audio calls. So getting started with it is pretty simple. We obviously create an account on Cloudflare, get access to the API, install the real-time kit package, set up the basic method. So, you know, you set up your real-time kit, initialize the kit and basically get the auth token. As soon as you're done, you incorporate the real-time kit meeting component. So if you see this very straightaway simple component, this gives you access to a complete full -fledged UI that you're seeing here right now. And, you know, just to show you this very quickly, this is a proper functioning call, right? Running right here. Wait, in the docs, it has a real live functioning call, you're telling me? Yeah. I mean, not only that, you know, this is a live editor. So if you change anything, the way we've made it is exactly what you said, right? Making sure that developers really enjoy working with it, right? So your doc should be somewhere you could, you know, play out as a sandbox. And this is kind of how the call looks like in a full screen. And this is all out of the box. And as you saw, you know, you have all basic calling functionalities, you have chat already built in, you know, everything else you can actually screen share within this. I don't want to do a screen share within a screen. It's going to get like Inception if you do like a screen share and a call of a call. Yeah, but yeah, exactly. So this is pretty much how easy it is to build with Realtime Kit, you know, get started, pick up your API keys, incorporate the meeting component, and you're done. That's as simple as it can get. Uh, wild. I can't wait personally to get into those docs. I'm like, I'm just gonna lose a couple hours of fun there. Great work. What, what are y'all excited to see people build with this? Like, as we're getting in this into the hands of the world, like, what are you most excited? What kind of applications you think you'll see? And where are you eager to perhaps people show it off to you? So, again, this would be a very, you know, different answer, probably for each one of us, because it's essentially our view of how we see apps, you know, taking a direction with like access to Realtime. So I would categorize into two types of apps. One is this entire spectrum of, you know, AI voice agents. So if you, if you look at the way we've designed Realtime Kit, right, it's easy to build. It gives you access to cloud-first superior infrastructure, right? And that is not limited to just our Anycast network where you're like, hey, lowest latency, but it's also making sure you have low latency and then the spectrum of Cloudflare products that enable AI apps, right? So being able to stitch all of that together. So definitely AI voice agents is one place where it's a no brainer to, you know, pick up the Realtime Kit, spin up a voice agent, which is leveraging extremely secure and, you know, ultra low latency network, because that's where latency really counts, as I mentioned earlier, right? You would notice even a slight hundred millisecond difference. Similarly, the other bucket of apps is just apps around wherever you need to bring interactivity as a part of the experience, right? Where video is not just one of the things, like it's a core part of the experience. So to give you an example, any sort of telemedicine app today where you connect remotely with your doctor patients, the video experience needs to be native, right? You can't have users move to a third party for a video and then, you know, try to track everything, manage everything. Similarly, if you just look at the broad spectrum of apps around education, you know, virtual learning, all of that, video needs to be a core part of it. You don't want to have a curriculum and the learning experience so split up that you can't control it, right? Likewise, you have the entire spectrum of proctoring and monitoring, right? Like again, so these are some of the apps that we're pretty sure and confident that we're going to see a lot of adoption and, you know, usage in. And then the best part about the way the kit is designed is, you know, think of them like building blocks. So it's essentially going to be limited by your imagination, right? Like you can build whatever you can imagine with this and make sure that that is truly interactive and has a very, you know, seamless collaborative experience. Yeah, I mean, I think to add to what Abhishek said, if you, again, I'm going to tie this to the broader Cloudflare story, right? I think Cloudflare historically has been known for a few things, such as helping you ship really fast, helping you be able to trust that as you scale, you're not going to go broke, right? And then just having a culture that where you can just actually, you know, when we say we're privacy focused, we actually mean it. They're not just buzzwords, right? So if you apply all of these three teams, I think it applies to building real-time apps, maybe even more than many of the other things that people build on Cloudflare, right? Abhishek mentioned like healthcare, right? Audio, video, and healthcare are some of the most sensitive types of use cases you can have, right? The data that's going through. We think we're natural partners for companies who are ambitious, you know, small teams who have an idea and have very basic, you know, like shared ideals around privacy, around, you know, cost and helping those teams ship the product, not so much get lost in the tech, right? So I think that is what excites me is how, besides just the real-time piece, the other values that we have around privacy, the things that we're doing with AI, how that can plug into the real-time ideas that our customers want to ship. Yeah, I love the healthcare use case. It may be TMI, but, you know, this is this developer week stream, but I do all my therapy on a, like, you know, video call and the system, it's so funny when you log in, it has a specific announcement around, hey, the like little emojis that pop up on Mac are not us. And I was thinking like that came probably from like, you know, a therapist, like sitting here like this, and then like a thumbs up pops up and like their patient is like, oh my gosh, right? And it's like a silly example, but it goes to show like some of these use cases that you want to be sure that they're really safe and reasonable in how they interact. And I think, you know, there's just stuff I don't want to do on a Zoom or Google Meet because I have different expectations around, you know, privacy and security and experience of it. So I love that example for sure. Yeah, I find myself doing that too. Every therapy session when I switch therapists or they switch vendors, I'm looking at WebRTC internals to see what's going on under the hood. Yeah, yeah. A rare like nerd thing we all have in common. We're like, okay, I need help. But first I look at the WebRTC internals here. What about, you know, the future of where you see this going? So we talk a little bit about the today, like, you know, any anything you see in the future that we haven't touched on that you're excited about? Yeah, I mean, I think we are, you know, each week there are new things that are being innovated around AI agents. We think the Cloudflare network provides the perfect highway for delivering the, you know, think of it like there is the Internet and there's a normal cellular network, right, for delivering audio content. We think, just like you have the AT&Ts of the world, we have the best highway for this type of data over the Internet. And what we want to provide is the interface so that you don't have to worry too much about the internal details and stitching together regions and things like that. You just are able to say that, hey, I want my users to be able to speak. I want what is being spoken to be routed to, you know, these different destinations and then the output to be able to deliver it back to the user, right? We almost want to make it configurable and as customizable as you want. So the full spectrum of the flexibility from ship it in hours to I want it to be super customizable with code. I wish I can add more to that. No, I think, you know, I'm like on a similar page, as I mentioned, right? One of the biggest use cases I see is everything around AI agents and apps and specifically being able to leverage the Cloudflare network for it. Because as I mentioned, right, like I think the Cloudflare infrastructure is perfectly positioned for this, right? The way it's designed, all the other set of tools and functionalities that we already offer, it just makes sense to become the default network for anything in and around, you know, AI agents. So I would also say that one of the, you know, biggest use cases that I see coming up in the future and like for us as well, right, as we continue developing the kit, right, one part of it is just making sure it's easy for you to spin up something and, you know, ship in hours. The other bit is making sure it's completely integrated with the rest of the offerings that we can think of and, you know, we can provide as a whole. So that's the bit where a lot of things in the future are yet to come. And today it's more about getting you started quickly because it makes sense, right? Like you need to be able to do that first and then you think about what next, what to build further. So yeah, with this, we're just kicking off getting started very quickly on top of Cloudflare's infrastructure and building apps around real-time. Yeah, and perfect transition to what I wanted to ask. So thank you. And some of a selfish question because I want to know this for me. How do we as developers get started? Where do we go? How do we access this? How do we start seeing some code? Yeah, so if you have a Cloudflare account, you will see real-time as an option on your left nav and you will be able to go to real -time kit and request an invite. If you are not a Cloudflare customer, don't have an account, you can go to realtime .Cloudflare.com, learn, you know, a lot more than what we even covered here about what the real-time kit is going to offer and then request an invite. Amazing. Well, and you hang out on Discord, on Twitter or whatever? Where do you hang out? How do people find you? Yeah, I mean, I think Discord, Twitter, I'm personally very active on Twitter, but I also know we have team members that are active on Discord. Cool. Discord.Cloudflare.com, I'll do a plug there. Abhishek, where do you hang out? Can people bug you anyway? Or are you like a secret? So I'm very easily accessible across Twitter, as well as surprisingly LinkedIn. That's more from the founder life. So yeah, and Discord too, right? So any of these places, you can just directly message me. I have my DMs open all the time. You know, happy to help out if you want to reach out, like whatever's the easiest open platform that you see me just message directly. That's good enough. Amazing. And yeah, somehow LinkedIn is cool again. I think it's all come around and it's like, oh, now we're on LinkedIn again. I don't know. Maybe cool is the wrong word, but at least we're on there. I would say, yeah, active again, right? I'm not cool yet, so active definitely. Oh, incredible. Well, thank you both. And thanks everybody for watching and hanging out. Realtime .Cloudflare.com, check it out. Find any of us on any of the channels and bug us and tell us what you are excited about, what you want, and we'd love to hear it. Zedd, Abhishek, thank you so much for the time and we'll see everyone next time.