Nevi Shah 0:09
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.