Nevi Shah 0:09
Thank you so much, Brian, I am so thrilled to be here. I remember in I think it was 2021. When I joined CloudFlare, I was kind of getting to know the broader web development space, I was watching videos and tutorials and talks, many from some of the people who are on the speaker list. So really a full circle moment for me to be here talking to you all about jam stack, and how it truly is an unfair advantage. My name is Nevi Shah, I am a product manager at Cloudflare. Most of you probably know Cloudflare as the internet security infrastructure CDN company, and rest assured that is still a part of our brands. But I work on our developer platform where we are building out a slew of products to help developers build, ship and monitor every piece of their full stack application. I work specifically on Cloudflare pages, which started as our integrated CI/CD Jamstack offering. And I also worked on Cloudflare workers, which is our serverless compute offering. And I’ve been building developer products as part of the early part of my career. But I wasn’t born a developer, I wasn’t born a developer out of the womb, which I know some of you are. And it’s taken me time to learn about development about my users about the industry. And it’s been quite a ride. I really feel like the pendulum of opinions on system architecture for web apps really swings far right, and then far left, and then back and forth. And I remember feeling like I had something love trust issues because the gold standard changes so often, right? You dive in so deeply on something and then two minutes later, you’re on Twitter, and it changes. But as a PM, I’ve learned that there really is no wrong way to build an application. And everyday everyone does things differently. So though many people watching this may disagree with me with a burning passion. I’ve learned from many of my users that everyone has their own priorities, right? Everyone has their own set of trade offs that they’re willing to make, from user experience, to developer experience, to server to sock to client to performance. And that’s okay, right? I’ve seen the different priorities. It’s been my job as a pm to make sure that I cater to those different priorities. And you’ll hear me say this a lot in this presentation. There is no right way to build an application. We’ve come so far in our thinking on system architecture that I think it might be really helpful first, and I’m sure we’ve done a lot of this in the past couple days. But I thought it might be helpful to just kind of talk about how did we actually get here. After that, I’ll dive into why I think jam stack is a platform is a platform PMs secret weapon when they decouple the front end and the back end. So dating back to the ancient 2010. And prior, the norm at the time was writing in something like PHP and using a single server as your back end. This was expensive, it was difficult to maintain and scale, which was pretty, making it pretty inaccessible and pretty nonperformance. But we didn’t know any better, we expected the love that we thought we deserved. And then later in the middle of the TLS and 10 decade app sort of trending towards being fully dynamic and using more and more JavaScript. And part of the advent of JAMstack was to trend towards static site generators like Gatsby like Hugo and companies like Cloudflare. And fastly really started introducing the idea of a CDN earlier on in that decade. So I feel like the tech was just there, it gave performance advantages and allows you to load better scale better, which was a huge, huge improvement from PHP and single server lands. So a symphony of great things you could say. Then in the early 2020s, the era of compute at the edge really dawned on us right frameworks, like remix and next Jas and spell kit and Astro all really popped off in this age of server side rendering and achieve things like faster load times better SEO less key spinners. So really an immense improvement on users and experience or end users experience. And then recently, we started seeing frameworks push SSR even further, and now can offer a seamless developer experience even for interacting with your database. So although this is a slick experience, and innovation in the way we make apps, it’s worth stopping to consider what we lose if we fully adopt a paradigm like this. And so before everyone starts shouting, my point in saying all of this is, I just want to give you some food for thought before you start a campaign to re architect your company’s app. Right? I want to give you my own experience pm in a jam stack product as your witness. So a cloud player, we’re building a massive application for our users who happened to be developers where we thought a lot about the system architecture of our app. We offer a platform with Compute and data storage and developer services, all that you can access on Dascha developer.com and other interaction services. Most people think that product managers don’t care about product architecture they think that we just care about design require means and how it looks and how it feels. And that may be true for some PMs. But for a platform PM, it is crucial for me to understand what the system architecture is. And here is why I care about the architecture of my product, because both internally and externally, it has its impacts internally. So my engineers can be productive and ship fast when developing new features, and externally so that my users are able to interact with my product and understand how it works and build a really good mental model around it. Our architecture, specifically follows the JAMstack principles. And we are really reaping the benefits as we think about product development and road mapping. So let’s talk a little more about cloudflare.com. When we think about Cloudflare is app, it’s actually dasht cloudflare.com. Let’s consider it first in two different worlds. The first one being coupled, and the other being decoupled, which is actually what it is today. In a coupled architecture, you can build your application and deploy it entirely on software.com. Let’s say your users will interact with the front end and the front end only. And behind the scenes, you have front end back end and database code. And like I said, your user can only access the products via the front end. And this is typical for a lot of applications. Again, no right way, no wrong way. But this was not the right setup for Cloudflare. Now, in a decoupled architecture, you still have your front end on cloudflare.com. But now you also have this additional layer of cloudflare.com/api, which hosts your back end and speaks to your data store. In addition to a user interacting with the backend, through the front end, users now have the opportunity to interact with your app through and through other interactions services in the form of let’s say, a CLI. And a Cloudflare, this kind of additional interaction surface is super critical to us. And it’s super important for us to kind of make this architectural decision and distinction. We know that our users really, really need to interact with our platform in ways that are not just the UI, we obviously have developers on our platform that are novice and new and love to use the UI love to use our code editor. But we equally have advanced developers building with advanced use cases. So we really want to be able to allow our users to directly talk to the API or directly to Cloudflare CLI. And without decoupling the front end and back end, none of that would be possible. And developers would basically just be interacting with our dashboard, which really limits the experience and limits where our product can go. And so by separating, we’re able to build all these layers on top of the API and provide developers with flexibility to build how they want. But of course, all these layers really need a solid foundation first, right, you’re really building on top of your API needs to be solid needs to be rock solid. So in order to successfully build a product that has its own data layer, the first thing that we need to do is develop a good flipping API. My advice to everyone define your products, information architecture, and let it guide you. What do I mean by information architecture, it means a lot of different things to a lot of different people. To me, an information architecture or IA is, by definition, an operational map on how a product acts and functions. It provides somewhat of a mental model to your users, but also is a really key artifact to my engineering team to design out the system. When developing our I think we spend a lot of time talking to our users. So we get the IA right, we pour over nuances. And consider what we offer today, what we’re going to offer tomorrow, what we’re going to offer next year, and we want to really make sense of the world that we’re creating. This is an example of clouds or pages, the product that I work on, which is a product that helps to build and deploy full stack web applications. But we’ve created this concept of a project. And we’re building our entire information architecture around that concept of a project. So let’s talk about this concept. Let’s talk about this concept of a project. A project is any combination of static assets and a worker, every change that you make to the project creates a deployment. And that deployment can be made to your production environment, it can be made to preview environment. And then a project can be bound to a resource. So let’s see one database or an R2 Blob Storage bucket. This is kind of the basic blueprint of Cloudflare Pages. And you can see it’s basically like, you can say it’s a set of rules that a product has to follow in order to create its relationships with other parts of the platform with things outside of the platform. And of course, there are more details than just this screenshot regarding the details of Cloudflare Pages and its information architecture, but this is the general blueprint. It’s the way that we basically describe our product and documentation. It’s the way that we, you know, build out our API’s as engineers. It’s the way that our designers reference our products when building out our UI. It’s really what we reference when we’re me Getting significant changes to our platform, because at the end of the day, it’s the shared vision that everyone knows about at its core.

Nevi Shah 10:08
Once you actually put time into thinking about your information architecture, it really forces you to think about the contract between your front end and your back end. And when building your application, referencing your information architecture, it makes it that much easier to build out new features and figure out where it fits into the puzzle. When you decouple, on top of building new interaction services, like a CLI or maybe a mobile app, the biggest thing decoupling your front end and back end unlocks is the ability to create an endless amount of integrations. And this has been probably Cloudflare’s biggest win. Thus far, in my opinion, the proof is really in the pudding. So I’m going to show you how we did this at Cloudflare. The first type of integration you’ll be able to build is an internal integration. So if you’re building a platform with many different products with open API’s, you can easily make them talk to each other. So with pages, we’ve been able to build out a plethora of integrations within Cloudflare, just by using the products API. And I’ll just name a few to give you some examples. So when you build a pages project, you get this default pages dot depth domain. So I made a project. My project is called Nevi dot pages at Dev. And so after deploying, you can integrate easily with a Cloudflare product called SSL for SAS, which does certificate issuing and management by proxying traffic through Cloudflare edge. This lets users easily add a custom domain to every project. So now I have my Nebby dot pages dot dev project. Now I want to make it nevi.com. Easy, I use SSL for SAS, the integration with SSL for SAS, no problem. Additionally, while pages in the early days was just for static sites, we just you can just deploy static sites, I think that was back in 2021, we realized we could actually unlock dynamic applications for our users by just speaking to the workers API, right. And workers, like I said is our serverless compute offering. All we needed to do was really just call the API. These were both things that we were able to do pretty rapidly in terms of development. And you can think of this as sort of a microservice approach to products. It also really speaks to how we’re really big fans of dogfooding at Cloudflare. Right, we’re always our first customer, so we can prove that other people can be our customers too, which I think is pretty cool. That brings me to third party integrations. So an open API can also be used in the exact same way as internal integrations, but for third party. So now you’re taking your product, and you’re building strategic connections so that you can meet your users where they are. And as the benefit, you get to tap into user bases that you would not have previously been able to tap into before, you can build these strong partnerships, meet with other players in the industry, instead of trying to reinvent the wheel and build everything out yourself. As long as your integrations fit within the information architecture. And you’re able to call your API, you’ve added more functionality without the headache of entirely re architecting your app. So Cloudflare has worked with a couple of incredible partners in the industry LaunchDarkly built in integration with Cloudflare for their feature flag product entirely on Open API on our open API’s. We partnered with super bass to offer an easy database integration with any app deployed on Cloudflare. And then we’ve also partnered with century to build a logging pipeline built on for any app built on Cloudflare to go directly to this century app monitoring platform. So these are just three of many, many integrations that we’ve built with workers and pages. But of course, Cloudflare is infamously known for building out and shipping out new products. And so although we are still doing this, we know that developers have preferences on the tools and the workflows that they’d like to build. And so it’s important for us to really consider the future of integrations. So again, these are just a few of many integrations, we’re only getting started. It is really exciting to me as a pm to to have the opportunity to build with integrations. I just think that like when I see integrations happening, it just reminds me of like new friendships blossoming between two parties. So I think kind of a nice way to look at it. But again, it’s not always an official partnership. It’s not always just like official collaboration where an integration must exist. What’s really meaningful to us at Cloudflare is building on top of our API’s also means that any independent developer can build with us to whether you’re starting your next big idea for your company, or you’re playing around with AR API’s for a school project. We see that developers do it all. So I want to give you two really great examples. First example is party kit, which is a multiplayer App Framework and platform and it was started by Sunil pi, which is someone I really admire. With Cloud flares API’s, it’s able to offer a direct deploy to Cloudflare built in, it’s also able to offer a white label experience building multiplayer apps, which is really, really cool. And this would only be possible if we thought it because we thought about building and support In platforms when building out our AI, or information architecture, so we’re constantly kind of thinking about products and for platform focus, and the prioritization of kind of scaling capabilities is also really important to us. My last example is with the help of all of our guests like what the what the use of our API’s that are open different frameworks can also easily ensure smooth deployment on our platform, right. So we have a really great team at CloudFlare, that works closely with framework authors to make sure that the development spirit experience just kind of works, just works on Cloudflare. It also helps frameworks take advantage of the primitives on our platform. So a really good example of this is the framework remix enables developers to utilize features like asset hosting, and our D one database that we offer. So in short, a good AI means you can build on top of yourself to prove that others can build on top of you too. And so I really urge you to do this be your own customer zero, strengthen your product, let it interact with broader ecosystems. And so circling back, if you couple your front end and back end, there is nothing inherently wrong with that, right? I see developers doing this all the time. If you do, just know that you are missing out on an opportunity to build something huge and to add on to it, just food. But it really wouldn’t be fair for me to give this talk and not discuss some of the challenges that you might face. by decoupling your front end and back end. I’m not gonna lie, it is not easy to write an information architecture, it takes time and it takes buy in. And if you’re on a large team, it can be a significant amount of work upfront to get it right. It’s a joint conversation that happens between products between design between engineering. And so just know that the conversations can get spicy, and there’s nothing wrong with that. It’s good healthy conversation, it’s a great way to set vision. But equally, if you take your time to write your IA and you create your API’s, and you do it, well, you’re golden. However, if you have to revisit your information architecture, you might run into issues. And let me tell you, you will change your IA because as your product evolves, so to the requirements, and so does the industry, and so do your users. And this can mean breaking changes, right breaking changes for your users or forcing you to consider things like API versioning, and sunsetting, and timelines and rewriting documentations, which in my head sounds really scary. And every time I think about things like that with my own product, my heart skips a beat a little bit. But it is a solvable problem, right? We’ve seen many companies like Stripe and GitHub who have stuck the landing on things like this. And I’ve implemented compatibility dates, which can really help ease this transition. So Cloudflare really loves this pattern. So much so that we’ve actually implemented compatibility dates and our own workers one time. Obviously, if you’re an independent developer with a great idea that you want to get out the door, it makes sense to couple your front end and your back end, you want to get out a prototype, and you want to just build the thing and not spend so much time talking and thinking and discussing. But when you’re building a production service, and you need a more complete offering, that’s when you should think about decoupling, that’s when you should think about decoupling, right? Invest your time into a good IA and I promise it will pay off. It is a lot of conversation that happens up front is a conversation that takes a long time. But it does set a really clear vision for your team going forward and gets everybody on the same page that you all know what you’re building. And you all know what the mission is. I also didn’t want to end this talk without discussing how Cloudflare really is thinking about what’s next for compute at the edge. So at CloudFlare, we are continuing to explore new architectures and ways to run your application on our global network. Cloudflare has network spans across I think, I think it’s like 310 Plus cities around the world now. And we’ve built products like workers where you can run and deploy apps in each of these cities, which has been incredible for our users around the globe. However, while global applications like these will run closer to your users, no matter where they are, we recognize that that might not be the most performant in all cases, specifically, when you’re building a complex app that depends on data. If that data is regional or localized, you may run into issues with your application. So we are actually taking a two pronged approach in solving this problem. And what do I mean by that? Let’s say that you have data in one central location, let’s say Mumbai, India, users all over the world. But you want to let’s look specifically at the example of a user in Salt Lake City. You have a really noisy application and there is a lot of back and forth conversation between your app and your database. And normally the back and forth would take entire trips from India to Denver and India to Denver and India to Denver so 150 to 215 milliseconds each. That is a very meaningful performance penalty.

Nevi Shah 20:06
At CloudFlare, we don’t think that’s acceptable, we think we can do it better, we think there is a better way to solve this problem. So we launched smart placement, which moves compute to the most performing location next to your data. So in this example, data is still in India, but instead of the compute happening closest to the user, which previously was in Denver, we’re moving the compute closer to India. So instead of going back and forth, India to Denver, every single time, it’s taking these many hops back and forth from data to closest node, which are both now in India. And then it takes one trip back to the user, just once. So you’re only doing that really large round trip time 150 to 250 milliseconds. I feel like this is really, really, really huge, right? Instead of your database sitting in one centralized location, it is or sorry, instead of your data, taking that round trip many, many times, it’s just once. I think that, when thinking about this problem, though, we’re also thinking of it in another way. So another thing that we are doing is building out a product called D one, which is our native serverless database. The goal is to bring your data closer to your users. So think about it like this in one in one scenario, smart placement, we’re talking about data being in one location, D one, we’re talking about location being closer to users, and potentially, instead of it being in one place, kind of break sharding your data across the network. These two concepts of a D one database and smart placement are a little bit at odds with each other if you think about it, but I think it’s important at Cloudflare for us to discover and explore and invest in both of these spaces, and a call through we really urge everyone else to explore this space as well and to work with us on these kinds of endeavors. I want to leave you with a couple of parting thoughts as it relates to decouple on your app. This is not a declaration of war on server side rendering, right, you can absolutely still decouple and reap the benefits of SSR. It’s increasingly powerful. And it’s still a great pattern for a lot of apps. All I’m hyping up in this talk is a separation between data layer and the UI, you know, the world is not black and white. And I really do think you can still have it all. The next thing I want to talk about is audit your information architectures. If you’ve never heard of an information architecture, if you’ve never written an information architecture, definitely do that. And if you haven’t already, see if you can audit your existing one and make sense of your product, check for inconsistencies talk to your users. It’s a great exercise to do with your team and a great tool and building out your roadmaps and thinking about now next and beyond for your product. Finally, I’ve said this probably three or four times in this talk already, and I will say it again, there is no right way to build an application. Okay, so low developers don’t feel pressure to chase new stuff. keep on keepin on, right. It’s exciting, it’s sexy, but stay productive. When you have a moment, peek up and have a look, tinker around, try the new tech, it’s always going to be there. But it’s important to stay productive. It’s important to keep chipping. I wanted to give a really huge thanks to Brian and the the jam team. Thank you so much to everyone in this community as well, the founders, the framework authors, the indie developers, it’s so so great to see the continued innovation from all of you. You are genuinely where I get my energy and my motivation to keep building out a better roadmap. And one last piece of advice and thoughts I will leave you with is I encourage you all to speak up because your voice matters. If you want the web to change, all you really have to do is ask. So thank you so much everyone and Happy Happy building. And I will stop sharing.

Brian Rinaldi 24:03
Thanks, Nevi that was great. You know, I think it’s interesting to think about how we’re developing these applications more from like a product perspective, because I think a lot of developers tend to be like, I’m just, you know, a typical developers like, I’m just gonna jump into code. And I think some of the steps you laid out there are really great. I think that’s okay.

Nevi Shah 24:25
As I mentioned, like, I think I also am someone who loves to jump into things, right. It does take patience. It takes patience to plan out what you want your app to look like. But it’s important to prototype. It’s important like at Cloudflare we ship fast and we be are scrappy, and we do things really quickly and iterate fast. But if you prove your concept out, there’s nothing stopping you from starting it later. And then decoupling your front end and back end after. Yep,

Brian Rinaldi 24:53
yeah, for sure. I mean, the whole, the lies you kind of point out the whole idea here we’re talking about is decoupling. You know, Matt Biilmann talked about it yesterday. And I mean, it’s just really kind of a key tenant of the types of applications we’re trying to build. So I do, I did have, if anybody in the audience has questions, I did have one question I’ll get to in a moment. But I’d love for people to post their questions in there. I think I want to talk a little bit about how you all thought about this data stuff, because I think it’s really, really important that data at the edge things that you’ve talked about, because I’ve been talking about the edge for like, you know, couple years, particularly edge like serverless stuff, and Cloudflare workers was kind of like one of the at the forefront of this. But I found that developers have a tough time getting wrapping their heads around how this works, because of exactly the kinds of problems that you point out, which is that if I, you know, it seems like it will be faster to move a function closer to my end user. But if you really have to think about what your function is doing and where the data is coming from, and it’s so, you know, in theory, if you’re only getting one piece of data, get it from single locations, it probably is faster. But in many cases, I’m getting a piece of data, then then coming back and saying, Oh, hey, you know, based on this piece of data, I need to go do this, and I need to get this. And so like, you’re assembling a whole bunch of things. And so you end up making that super long, round trip. So moving things closer to the end user only made the problem worse, actually than it would have. You know, and it really depends on the scenario. And so like, I think, I think the smart placement is interesting to me, because it just kind of at least as I understand it, please correct me if I’m wrong, it just does it for you. Like it does set thinking for you without you having to be like, Okay, this one, move this closer to the to the data center in this one, move it closer to the user.

Nevi Shah 27:00
Exactly. And this is a huge deal, I think when we launched this because it’s something that should be accessible, right? It’s something that users should not have to think about. Our developers should not have to bear the burden of thinking about where to place the compute and where to place like all the pieces of their application. It is literally a toggle in our in your project dashboard. If you go to your worker, or your pages project, it is literally just a toggle, and we want to do all of those calculations for you. So you don’t have to think about it.

Brian Rinaldi 27:35
Okay, so once you flip on that toggle, it’s going to basically automatically determine the best place

Nevi Shah 27:39
Yes. To put that request cycles, kind of like calibrate learn. But it’s not easy. Yeah,

Brian Rinaldi 27:48
that’s, that’s amazing. Because that, like it is is a really difficult problem. And even when I’ve tried to explain it, it’s like, well, it’s not necessarily so straightforward to solve. If you’re just a developer trying to like, okay, is this one gonna make be faster or slower? I mean, I how do I measure that? Perfectly? Okay, so I’m gonna get to the questions here. So Bryce asks, okay, he says, I know it’s not your product. But can you offer any insight on Cloudflare fonts seems to have gone quietly.

Nevi Shah 28:21
I don’t have information on Cloudflare fonts, but I can make a note, and I can look for it. And when I if I see you in the discord, and you want to message me, I’ll tell you what I find.

Brian Rinaldi 28:32
Okay, all right. That sounds good. Sergei asked, Does Cloudflare pages rely on its own framework? Or will it support other frameworks?

Nevi Shah 28:41
Yeah, really good question. Um, Cloudflare is, and you’ll hear me say this, if you’ve listened to any of my other talks as well. Cloudflare is the company and I think we truly believe that we should meet developers where they are right. There are a lot of our competitor companies and a bunch of other players in the space that do build out their own frameworks. And that’s great. We know that our developers have a really wide range of preferences. And like I said, tools and frameworks and workflows. So it is important to us to support what our developers want. We have a team, like I said, dedicated to working with different framework authors. So to answer your question, not right now. And not what I can see are really big priority is to make sure that we’re working with some of the best framework authors and some of the most popular frameworks that our developers love.

Brian Rinaldi 29:34
Okay, yeah. And I know, I know, like, you know, I’ve done some work with Cloudflare pages. I’ve used Hugo there. I think I’ve posted next Jas there. I am fairly certain you’re all supports Velcade as well. Yeah. Yes. Astro. Yes,

Nevi Shah 29:50
exactly. We, we, if you go to the documentation, there’s like a list of probably 20 or 30 static frameworks that we support. And then our team now is built on kind of the server side server side rendered support on pages as well.

Brian Rinaldi 30:03
Awesome. Yeah. So so yeah. So Sergey works with probably the framework that you’re that you’re using is, is most likely supported. Okay, so Lee asks any estimate on when D one will leave public beta?

Nevi Shah 30:23
I think it will leave public beta very soon. And I can’t quantify that because I’m not the PM, and I don’t want to put words in her mouth. But the team is making some really, really great progress. We do have an innovation week coming up. So I know, there’s gonna be a lot of really great announcements on that. But I will leave it to Vita, to tell. Okay,

Brian Rinaldi 30:47
well, I mean, if I know anything about your different weeks, the innovation week, there’s gonna be a lot of announcements. I’ve even like, you know, we have obviously, I’m friends with Don, who also works there, as you know, and like I’ve had conversations, like, you know, I love your weeks, because it’s like, so exciting. So like, I get lost, I can’t keep up. It’s so many announcements in there. It’s hard to keep track.

Nevi Shah 31:13
It’s funny. I, I, I orchestrated the week last developer week, and I got lost in the announcements. And I think one thing that we’re really focusing on is making sure that we really hit home and all of the announcements that we do have this year, so maybe not having a billion announcements, but really focusing on like, what are the things? What is the story that we’re trying to tell? What are the best things that our developers need? And what’s going to solve their pain points?

Brian Rinaldi 31:37
Yeah, for sure. And whether it’s Sergei who asked the question about frameworks has, you know, he had completely missed out on particular pages. And now, you know, obviously, now is going to check them out. You know, and I’ve used them before, too. And, and it’s a really great product. In fact, I think it should be clear, also, like the way you support SSR, that, that you have the ability to connect workers and pages. So you have like the it’s actually even easy to like, just throw a worker into your Exactly. And have that deployed automatically, if you want to. Yeah, yeah. And about that feature. Yeah.

Nevi Shah 32:15
So we, like I said, we kind of announced pages thinking that this would be for static apps. And we realized, like, hey, we have this whole serverless compute platform that we can easily bring into this product. And so basically, how it works is you have a, you have your static asset code, you have your code for your app, you can basically add a functions folder into your project, drop your functions in there, and we will deploy your functions alongside your static assets. And so really, what we’re doing behind the scenes is we are taking all of your functions, and we’re bundling it into a worker, and we’re deploying that function as a worker. You can also if you are a workers user, and you want to use a underscore workers.js file, you can also just drop an underscore worker such as file into your pages project. Another really cool thing that I will just kind of poke in here as we’re working on it. But pages on markers, if you have used both of these products are actually quite similar. They do similar things they have become, they’re kind of like Sister products, and they have different elements that are pretty similar. And so over the next kind of year or so we’re actually going to be working on unifying the deployment and development experience on pages and workers and kind of bring some of the gems of pages to workers like that CI CD integration. And then also bring kind of that developer experience side of of workers like configuration files and local development two pages as well. So you won’t ever have to choose between pages and workers, you kind of will just get the best of both worlds and this experience.

Brian Rinaldi 33:44
For sure. And you know, and I think another thing I would emphasize for folks I think it’s a it’s a different some of the things I built on Cloudflare is that workers not just the one I mean, like you have KV you have the which is the other there’s another data, the ability to store like the objects I forget durable objects. Yeah, you have the one I mean, as I said, like once you start thinking about the edge, like it’s easy to think like okay, the edge is going to solve performance like other box because but that’s only if you’re not thinking so much about like the data aspect of it. But you all have had like from the beginning the ability to add like the KV and was was something that was there from the start and you keep kind of expanding on those data options so that you can Yeah, start to get around that. And

Nevi Shah 34:43
we’re not only so we’re we work a lot on building out our own data primitives, right? So we have like Deewan durable objects and our to our to storage and we have key value store hyperdrive like so so many different things. We’re kind of throwing out there. We also like I was talking about are adding integrate easier integrations to databases as well. So I think we can, you can integrate with neon database and super bass. So again, we have our own primitives that we offer to if you want to build entirely on Cloudflare. But we also offer, you know, primitives outside of our platform, because we know that not everyone wants to build on them. People have their preferences.

Brian Rinaldi 35:26
Yeah, excellent. Yeah. I think hopefully people will check it out. Because I think it’s, it’s you all are doing some really innovative stuff. And just Yeah, so congrats on all the other products you’ve been releasing. I’m looking forward to innovation week and learning and trying to keep up with the 1000 releases you have coming out that I

Nevi Shah 35:44
am as well come find us on developer discord as well. I’m pretty active in it. If you have questions about pages, I will hunt down that Cloudflare fawns question if you can find me. But yeah, definitely, definitely come join us.