[{"data":1,"prerenderedAt":456},["ShallowReactive",2],{"footer-primary":3,"footer-secondary":93,"footer-description":119,"learning-things-i-love-to-hate-web-3-blockchain":121,"learning-things-i-love-to-hate-web-3-blockchain-next":180,"sales-reps":204},{"items":4},[5,29,49,69],{"id":6,"title":7,"url":8,"page":8,"children":9},"522e608a-77b0-4333-820d-d4f44be2ade1","Solutions",null,[10,15,20,25],{"id":11,"title":12,"url":8,"page":13},"fcafe85a-a798-4710-9e7a-776fe413aae5","Headless CMS",{"permalink":14},"/solutions/headless-cms",{"id":16,"title":17,"url":8,"page":18},"79972923-93cf-4777-9e32-5c9b0315fc10","Backend-as-a-Service",{"permalink":19},"/solutions/backend-as-a-service",{"id":21,"title":22,"url":8,"page":23},"0fa8d0c1-7b64-4f6f-939d-d7fdb99fc407","Product Information",{"permalink":24},"/solutions/product-information-management",{"id":26,"title":27,"url":28,"page":8},"63946d54-6052-4780-8ff4-91f5a9931dcc","100+ Things to Build","https://directus.io/blog/100-tools-apps-and-platforms-you-can-build-with-directus",{"id":30,"title":31,"url":8,"page":8,"children":32},"8ab4f9b1-f3e2-44d6-919b-011d91fe072f","Resources",[33,37,41,45],{"id":34,"title":35,"url":36,"page":8},"f951fb84-8777-4b84-9e91-996fe9d25483","Documentation","https://docs.directus.io",{"id":38,"title":39,"url":40,"page":8},"366febc7-a538-4c08-a326-e6204957f1e3","Guides","https://docs.directus.io/guides/",{"id":42,"title":43,"url":44,"page":8},"aeb9128e-1c5f-417f-863c-2449416433cd","Community","https://directus.chat",{"id":46,"title":47,"url":48,"page":8},"da1c2ed8-0a77-49b0-a903-49c56cb07de5","Release Notes","https://github.com/directus/directus/releases",{"id":50,"title":51,"url":8,"page":8,"children":52},"d61fae8c-7502-494a-822f-19ecff3d0256","Support",[53,57,61,65],{"id":54,"title":55,"url":56,"page":8},"8c43c781-7ebd-475f-a931-747e293c0a88","Issue Tracker","https://github.com/directus/directus/issues",{"id":58,"title":59,"url":60,"page":8},"d77bb78e-cf7b-4e01-932a-514414ba49d3","Feature Requests","https://github.com/directus/directus/discussions?discussions_q=is:open+sort:top",{"id":62,"title":63,"url":64,"page":8},"4346be2b-2c53-476e-b53b-becacec626a6","Community Chat","https://discord.com/channels/725371605378924594/741317677397704757",{"id":66,"title":67,"url":68,"page":8},"26c115d2-49f7-4edc-935e-d37d427fb89d","Cloud Dashboard","https://directus.cloud",{"id":70,"title":71,"url":8,"page":8,"children":72},"49141403-4f20-44ac-8453-25ace1265812","Organization",[73,78,84,88],{"id":74,"title":75,"url":76,"page":77},"1f36ea92-8a5e-47c8-914c-9822a8b9538a","About","/about",{"permalink":76},{"id":79,"title":80,"url":81,"page":82},"b84bf525-5471-4b14-a93c-225f6c386005","Careers","#",{"permalink":83},"/careers",{"id":85,"title":86,"url":87,"page":8},"86aabc3a-433d-434b-9efa-ad1d34be0a34","Brand Assets","https://drive.google.com/drive/folders/1lBOTba4RaA5ikqOn8Ewo4RYzD0XcymG9?usp=sharing",{"id":89,"title":90,"url":8,"page":91},"8d2fa1e3-198e-4405-81e1-2ceb858bc237","Contact",{"permalink":92},"/contact",{"items":94},[95,101,107,113],{"id":96,"title":97,"url":8,"page":98,"children":100},"8a1b7bfa-429d-4ffc-a650-2a5fdcf356da","Cloud Policies",{"permalink":99},"/cloud-policies",[],{"id":102,"title":103,"url":81,"page":104,"children":106},"bea848ef-828f-4306-8017-6b00ec5d4a0c","License",{"permalink":105},"/bsl",[],{"id":108,"title":109,"url":81,"page":110,"children":112},"4e914f47-4bee-42b7-b445-3119ee4196ef","Terms",{"permalink":111},"/terms",[],{"id":114,"title":115,"url":81,"page":116,"children":118},"ea69eda6-d317-4981-8421-fcabb1826bfd","Privacy",{"permalink":117},"/privacy",[],{"description":120},"\u003Cp>A composable backend to build your Headless CMS, BaaS, and more. \u003C/p>",{"id":122,"slug":123,"vimeo_id":124,"description":125,"tile":126,"length":127,"resources":128,"people":132,"episode_number":139,"published":140,"title":141,"video_transcript_html":142,"video_transcript_text":143,"content":8,"status":144,"episode_people":145,"recommendations":169,"season":170,"seo":8},"2d848504-0907-4315-b73e-94745042b868","web-3-blockchain","893747977","Kevin is joined by Ben Greenberg to tackle his learning on topics around Web3, blockchain, and decentralized apps. ","0a994d04-3d4a-46bf-b181-7b34cf50ff00",64,[129],{"name":130,"url":131},"Fuel","https://www.fuel.network/",[133,136],{"name":134,"url":135},"Ben Greenberg","https://twitter.com/hummusonrails",{"name":137,"url":138},"Kevin Lewis","https://directus.io/team/kevin-lewis",1,"2023-12-22","Web3, Blockchain, and dApps with Ben","\u003Cp>Speaker 0: Hello. My name's Kevin, and welcome to Learning Things I Love to Hate. The goal of this show is to go into situations with an open mind and learn more about the tech behind the hype. And in this episode, I'm joined by my dear friend, Ben Greenberg. Hello, Ben.\u003C/p>\u003Cp>Speaker 1: Hello, Kevin.\u003C/p>\u003Cp>Speaker 0: How are you doing today?\u003C/p>\u003Cp>Speaker 1: I am doing really well. How are you?\u003C/p>\u003Cp>Speaker 0: I'm fantastic for speaking to you. The topic of today is about web 3. There are so many realms of web 3, but because I don't know much about it at all, I thought let's start with a pretty generalist view. But before we jump into that, could you tell us a little bit about yourself, where you work, and just why why we're speaking about this topic.\u003C/p>\u003Cp>Speaker 1: Yeah. Absolutely. So, Kevin, it is so great to be joining you on this. We've known each other for quite a while, and it's such a pleasure to be always in conversation with you. So I am the head of DevRel at a company called Fuel, Fuel Labs.\u003C/p>\u003Cp>We are building the fastest execution layer on Ethereum, and we offer a really developer centric, platform with a set of developer tools focused primarily on the ability to build decentralized applications, dApps, as one might wanna call them, in the blockchain space and to be offering, really performant and intuitive and developer facing, developer forward, Outlook for developers to build, whatever they're looking to build and to get going in in the space.\u003C/p>\u003Cp>Speaker 0: So I don't understand some of those words. I don't know what an execution layer is. I'm sure we'll talk about that in a bit. But given that I don't know much about web 3, and I imagine quite a lot of the people watching this might be joining me, I thought we should start with this primer. And I thought a good way to start this is just a a real, like, candid point of just sharing some of my skepticisms that maybe we can address throughout this period we're chatting.\u003C/p>\u003Cp>If If we don't get to all of them, that's cool. But just at kind of a high level, the idea, the promise of decentralization, I think, is promising. And I think many people viewing will think, yes. Of course, that's promising in a world where large companies control large swaths of our data. But it always seems rooted in some kind of cryptocurrency, and I can't, in my mind, kind of sever and understand the difference between web 3 and decentralization and cryptocurrencies or tokens or something rooted in an area of tech that often is associated with scams.\u003C/p>\u003Cp>So maybe we can talk a bit about that because I I imagine it isn't all just one big, you know, interchangeable blob. And, also, I just don't get it. I don't know how how better way to say it. Like, if we just zoom in and look at the tech and forget all of the, like, idealistic, you know, backing of of why they exist, I don't really understand the characteristics of a web 3 application or a a dApp, and why they're unique and interesting. So I figured we might start by talking a bit about that, and then, we can get into some codes and maybe you can show me a little bit around.\u003C/p>\u003Cp>Speaker 1: That sounds lovely. So where should we start, Kevin? You you you lead us on this journey.\u003C/p>\u003Cp>Speaker 0: I think I kinda have these 2 main skepticisms. 1 around, decentralization and blockchain and cryptocurrency and kind of maybe just not even addressing the skepticism necessarily directly first at least, but what are the differences between these? That would be good. And then maybe talking about then we can jump into more more of the, like, technical, talking about what are the characteristics, like, how does it work at a high level, and then maybe we can jump into a demo. Does that work?\u003C/p>\u003Cp>Speaker 1: That sounds perfectly fine. So first of all, just a bit of background on my, involvement in this space. So I only came into web 3 blockchain, working in it professionally about a year and a half ago or so, and I too was incredibly skeptical for a very long period of time. And I actually think I remain still a bit of a skeptic on a lot of it, and I think that perspective is actually incredibly valuable when you're working in any space, regardless of whether it's blockchain or microservice architecture or, you know, you're working on Kubernetes clusters. It doesn't really matter what it is as long as you kind of have and retain that element of healthy, constructive criticism and skepticism, I think that just benefits your work and sort of everything you're going forward on.\u003C/p>\u003Cp>And so I empathize with you and I share a lot of that same sense of unsureness or like, what the what the heck is this? So having said that, I think for me, one of the ways that I've synthesized understanding what we're doing here is my involvement back in, like, connected networking, pre web kind of goes back to the early nineties, and I used to run something back when I was a kid. I'm not that old, but I used to run something back when I was a kid, and I begged my parents back then to get me a few phone lines to make this possible, but it was called the bulletin board system at BBS. And I don't know if you remember or even heard of BBS's. Kevin, you're so young.\u003C/p>\u003Cp>You don't know these things.\u003C/p>\u003Cp>Speaker 0: I don't wanna age you. I don't wanna necessarily make\u003C/p>\u003Cp>Speaker 1: you feel too. Let's let's talk about BBS's for a minute. So BBS is where these, like, pre web places online where people could dial in and there were shared discussion forums. There were file servers. You could share data.\u003C/p>\u003Cp>It might take you on a, you know, 24 ks modem, you know, an entire day to download something. There were, you know, text based role playing games where you had 2 or 3 turns a day. And that was my introduction to, I guess, what one might call the online community was through BBS. I used to run run-in San Diego where I'm from, born and raised, called the Freethinker BBS. That was my BBS.\u003C/p>\u003Cp>I was that kind of kid back in the days. And, and then the web came. Right? And, and the web began in the kind of the same modality where it was kind of run by people in their homes or, you know, local. You would you would have a web server on your running on your 48680 megahertz PC, in your basement somewhere, and you'd be serving websites on an Apache web server, you know, on your 486.\u003C/p>\u003Cp>And then, of course, things dramatically shift. We don't go through the whole history of the web. But, we got to a point where we are now where everything is essentially running on AWS. AWS is running AWS in every other service you're probably ever going to access is somehow connected to AWS. And I think part of what the premise of what we're what we're working on in this space is how can we get back to a place where people own more of their data, where people own more of the, access their data and you have more familiarity and a sense of confidence and where things live.\u003C/p>\u003Cp>And there's more of a communal aspect to everything we're trying to do. And so I think that is like at writ large from a balcony perspective, kind of like the idea. That's the idea. And the way that it's it's run-in a blockchain context is so one of the first questions people always ask, and I think it's a really good question, is that so I'm accessing some blockchain application. Where the where is the data?\u003C/p>\u003Cp>Like, where is that actual data living? You know? So if I know if I go to, you know, x slash Twitter or I go to, you know, Instagram or I go to any of these places, I have a general idea from a web developer where the data is. But where is the data on any kind of decentralized application? And the honest answer is that data is everywhere.\u003C/p>\u003Cp>The data is replicated and duplicated on people's computers and on organizations around the world, at all times. So that spread of the data is, I think, the first thing that we want to tackle and address, and then we can get to other parts as well. But I think understanding that is a fundamental premise to understanding everything else that the data is not owned in any central server or any central node. It's actually spread across, multiple, potentially countless nodes. Obviously, not countless.\u003C/p>\u003Cp>Nothing is infinite. But yes. Sorry?\u003C/p>\u003Cp>Speaker 0: No. Could I pause you for a moment and go back a couple of sec? Yeah.\u003C/p>\u003Cp>Speaker 1: Definitely not. Sorry.\u003C/p>\u003Cp>Speaker 0: The end. It's a it's a it's a train. We ain't stopping. So okay.\u003C/p>\u003Cp>Speaker 1: So Okay. We'll take a break. We're at the trade station. Let me get it done.\u003C/p>\u003Cp>Speaker 0: So on that train of thought, and I wanna come back to this train of thought, I wanna talk about the how does it work, right, and what are these nodes, how does the decentralization work, how can you trust it and so on and so forth? Can we take one step back? And I'm kinda curious again. What is the relationship between decent and maybe maybe you're like, no. Actually, we need to tackle them this way around for it to make sense.\u003C/p>\u003Cp>But I'm curious. What is the relationship between decentralized apps, cryptocurrency slash token slash some kind of fiscal value item and blockchain. And you you might just be like, of course, it's obvious, but, like, I really need\u003C/p>\u003Cp>Speaker 1: to start thinking about it. Rule of anything is to never assume that anything is obvious. And I think that's like the first lesson we help teach people writing documentation, technical documentation. Right. Don't ever assume what is obvious to you is obvious to others.\u003C/p>\u003Cp>So to answer that question, I think you actually need to unpack a little bit more. And you need to you need to kind of further accentuate the issues. So considering that the the entire enterprise rests on the notion that people will choose to run these nodes, these data warehouses that replicate the data across the world. So assume people are going to do that. That's the assumption.\u003C/p>\u003Cp>Then you baked into that assumption has to be some kind of incentivization model for how one does that. And unless you operate on a fully altruistic model of being where I will voluntarily give my, I will voluntarily give my my electricity costs and my Internet costs and and my hardware costs, and I'm just gonna do this for the betterment of humanity, which I think you you and I, of course, operate in that level. Everyone else, I mean, we don't really know. Yeah. But, you know, obviously, we work for our companies entirely altruistically.\u003C/p>\u003Cp>Then you have to do some kind of incentivization model baked into it. So I think that's the first layer. And then you may say to yourself, okay, that sounds all well and good, Ben, But why can't that incentivization model be based on euros or pounds or dollars or Canadian dollars or pesos or any other form of currency? Why why does it have to be a digital kind of currency? And I think to answer that question, you have to then make that question larger.\u003C/p>\u003Cp>What is the value of any digital collectible or digital good that exists in any way, shape, and form from the gaming enterprises and beyond. So for example, I have a couple sons. One of them, he's, you know, fast becoming a teenager, is really into this game called Fortnite. I didn't know Fortnite existed until he got into it. That's how much, you know, you know, how how much of a dad I am.\u003C/p>\u003Cp>But he got he's really into Fortnite. And there's these, like, digital collectibles and things you can do in Fortnite that are really valuable to him. Why is that valuable? It itself is not, doesn't hold intrinsic value. I mean, we could also argue that a US dollar doesn't hold intrinsic value by itself.\u003C/p>\u003Cp>It's representation of value, but he finds value in it. So then I think the question becomes, if you're building this system and you want it to be digital first, so maybe you ought to create the incentivization model also grounded in a digital value and a digital collectible, a digital good. So then that's the second the second layer. And the third layer is, okay, Ben, what about cryptocurrencies? And to that layer, because then you're now extrapolating to, okay, now it's value transcends the incentivization model of of hardware storage and, you know, incentivizing me to run a node, etc.\u003C/p>\u003Cp>Now it's suddenly a competing currency in the in the world competing against, you know, global government backed currencies. And to that question, Kevin, I'm gonna say I don't want to get into that because I am not a cryptocurrency person. Like that's not what interests me, I would say, in this space. It's not what motivates me. And I do think and I will end this little bit with a little bit of a caveat, there is a bit of a privilege to not be a cryptocurrency enthusiast in this space.\u003C/p>\u003Cp>For example, when I travel to parts of the world where the governments are less stable and the currency is less reliable, there is a, there is a deference, to cryptocurrency that I am unfamiliar with as someone who has only lived in first world global north countries. And I am and I was actually a bit taken by surprise by that, and that just reveals sort of the the the places that I've spent most of my life living in. But, you know, the the there are places I've been where the the first question is asked to pay for something, what's your wallet address?\u003C/p>\u003Cp>Speaker 0: So\u003C/p>\u003Cp>Speaker 1: At a store.\u003C/p>\u003Cp>Speaker 0: Interesting. The I don't I don't necessarily wanna go down the, like, and this is why cryptocurrency is a valuable track, which is, like, where this this area is going. But alright. So there's one question I have that I can't quite unpack yet, which is okay. To have people participate and participate, my understanding is there's, like, various degrees to participation, in a decentralized network, I suppose.\u003C/p>\u003Cp>You might correct me on my terminology by decentralized network or whatever. There's some kind of incentive. And, okay, your son gets Fortnite.\u003C/p>\u003Cp>Speaker 1: Whatever it whatever he gets.\u003C/p>\u003Cp>Speaker 0: Yeah. Sure. They don't have real world value. I mean, they possibly do. I think that is a whole marketplace, but whatever.\u003C/p>\u003Cp>Speaker 1: You know, I think in digital games in general, those things have quite a lot of value.\u003C/p>\u003Cp>Speaker 0: But let's assume let's assume they don't, and it's just I want I I want to give you something to participate. Actually, I'm going too far off the the end. Let me just ask the direct question. To to be involved in these networks, does it have to have be backed by some degree of, like, cryptocurrency token or something that converts into real money? For example, you were talking about I have sir a server in the basement, and it's running something, and that's great.\u003C/p>\u003Cp>And, you know, the web is weird, and we all host our own stuff. Now it's all hosted on, like, 20 data centers around the world, and now we'd like to go back to that. But, perhaps at that point in time, people were just hosting stuff altruistically. If I want people to participate in a decentralized thing that I build, why why is there a financial backing to or is there? Can can I just I'm gonna use some words perhaps ignorantly, stake some token for that has no real that isn't backed by anything that has real money.\u003C/p>\u003Cp>It's just a number of a thing that just exists. It just bites in the in the world, and that's that or does it always eventually get backed by one of these primitives that get traded?\u003C/p>\u003Cp>Speaker 1: Yeah. I think well, to there's a couple of different questions in that. But I think, first of all so there's, you know, obviously, I began this our conversation with a bit of nostalgia back to the BBS world. And the thing that I don't have nostalgia about in the BBS world is how far we've come and what one can accomplish with the modern web and the modern Internet infrastructure. And I don't think any of us I'm actually going to take that back.\u003C/p>\u003Cp>I don't. There are probably people out in the world who do, but I don't want to go back to a world of, you know, 48 ks, 24 ks modems. And I like the conveniences that are wrapped up into my phone into the ability to do the things that we do on on a daily basis. I happen to enjoy that. But that kind and I rely upon it.\u003C/p>\u003Cp>I more than enjoy upon I rely upon it. But that kind of sophisticated infrastructure requires a lot more than, you know, the the 486 80 megahertz p Intel PCs that, you know, that we used to run things on back in the day.\u003C/p>\u003Cp>Speaker 0: Oh, we. Yeah.\u003C/p>\u003Cp>Speaker 1: Yeah. The we. The we. The we. And so I think the infrastructure needs are a lot greater than they were back then.\u003C/p>\u003Cp>And so even if it was the case that there was a that you could assume a level of altruism, today you have to you have to compensate people for their, for their costs. And then the second layer in that question is, well, what about a translation at some point to a real world value of the incentivization token and tokenization? Like, does it ever have to does it always have to translate back to a real world value? You know, I don't really know. And I'm going to defer to other people who probably will comment in the comments on this or offer their own perspectives.\u003C/p>\u003Cp>I don't really know if a this is a philosophical question. Right? Do if something is valuable inside a system, does it also have to be able to translate to value external from that is external to the system? And and what are the bridges that one needs to create to create that kind of synchronicity of value from inside a system to outside a system? You know, for I mean, I don't know about you, but I and I but I know for myself, I remember I'm a member of communities where there are value things there are things that are valuable that we do in those communities that are not valuable outside those communities, levels of, communal participation, levels of voluntary service, actions we do as part of, you know, social and ethnic and sub communities in the world that don't translate to value outside of themselves.\u003C/p>\u003Cp>But do I need to have bridges to show that value, externalize that value, and and translate the value to a larger the larger community, you know, that we live in, whether it's in in the United States or in Germany or anywhere. And, you know, that's, like, that's a philosophical question. Right? That's a larger question. I think in the case of of blockchain tokenization, the answer has been demonstratively yes because they have built those bridges to to convert the token that is used as an incentivization model to US dollar or to euro or to I\u003C/p>\u003Cp>Speaker 0: think what I'm just thinking is if I wanted to host it and once again, I I wanna, I want us to move on a little bit in a moment, but maybe just for one more, like, quick quick bit here. But, like, if I just wanted to host a thing for me and my mates and this idea of it's decentralized just among us just among us, this is all cool. You know, there's, like, you know, 20 of us. Maybe it's like a school hacker club, whatever. And money doesn't need to be moving hands here.\u003C/p>\u003Cp>We're happy to spend some resources and not be reimbursed for them. It feels like just doing that is intrinsically wrapped up in a cryptocurrency of some kind. Even if it's small value, even if it's, like, not very much at all, it always from what I'm understanding, you can tell me no, actually. I'm not sure that's true, and it just happens to be true in most cases. It seems like it always ends up back in the world of Ethereum or Bitcoin or insert other I don't only know those 2.\u003C/p>\u003Cp>I'm sure there are.\u003C/p>\u003Cp>Speaker 1: I think that I don't think that's true. I think that, if you don't require an incentivization model to to help, inspire people, motivate people, get them involved, then I think you can build your socialist utopia and and everyone can donate their resources as they as they choose and donate their time and their hardware and their costs. And that's entire and that works to some scale. It doesn't work. I don't think I don't think it's been proven to to work at a scale that can power something that is trans transnational that\u003C/p>\u003Cp>Speaker 0: Sure, sure, sure. But that's much bigger. I'm just talking about, like, in theory, the concepts I'm about to we're about\u003C/p>\u003Cp>Speaker 1: to talk about. Can create tokenless blockchain, of course. Yeah. A 100%.\u003C/p>\u003Cp>Speaker 0: I mean, there there was no of course. I had no idea. I always thought there is no world in which that would, like, technically works, but it is. It just why would you slash? It's not very common, you know, or whatever.\u003C/p>\u003Cp>It only works as\u003C/p>\u003Cp>Speaker 1: And and and, actually caveat. Fascinatingly, there are private companies that have you and we'll maybe we'll get to this in a little bit, but there are private companies that have built blockchain networks internally that are not, we would call, decentralized, but they're using the primitives of blockchain. They're using blockchain in order for things like provenance, tracking, inventory tracking, things like that. And they're not using it with token because it's all within their system. It's employees using the thing that the incentivization in the company is the is the salary and the stock options.\u003C/p>\u003Cp>Yeah. And they're using blockchain for the for the utility of inventory tracking, let's say.\u003C/p>\u003Cp>Speaker 0: So the utility is what I the utility and the kind of these primitives and the structure, I'd love to talk about it. We're we're bumping up on you know, we're starting we've done about\u003C/p>\u003Cp>Speaker 1: 20 minutes. We're bumping. We're talking. We're getting everything.\u003C/p>\u003Cp>Speaker 0: Lots, that of already some of my assumptions have been dismantled, which is good. You know, that's that's why I invited you here. I wanted to genuinely learn more. There is I'd love to move on to a demo soon. But before we do that, maybe in, like, 5\u003C/p>\u003Cp>Speaker 1: ish You like my big Stanley Cup, by the way? This is the new rage in the United States. Everyone has these huge\u003C/p>\u003Cp>Speaker 0: Stanley Cup now. Some of my friends got them. You know? Some people would call them quite basic.\u003C/p>\u003Cp>Speaker 1: 40 ounces.\u003C/p>\u003Cp>Speaker 0: But you know what they're gonna\u003C/p>\u003Cp>Speaker 1: do, though? This is 40 ounces of water.\u003C/p>\u003Cp>Speaker 0: I've seen Starbucks have just come out with, like, a Christmassy one. I'm gonna date this video and the the time we're recording.\u003C/p>\u003Cp>Speaker 1: Yes. I know. You just did that.\u003C/p>\u003Cp>Speaker 0: That's a bit of a problem. It's this this lovely red, like, you you know, matte red one.\u003C/p>\u003Cp>Speaker 1: Yeah. That's nice. Yeah. But they\u003C/p>\u003Cp>Speaker 0: only sell it in the US\u003C/p>\u003Cp>Speaker 1: as well. Because we Americans, we really hydrate quite a lot, I guess, opposed to the Europeans. What was that type\u003C/p>\u003Cp>Speaker 0: of trash? Ice.\u003C/p>\u003Cp>Speaker 1: Right? The Europeans don't like to drink water as much as Americans do, apparently. There was a whole social media trend there.\u003C/p>\u003Cp>Speaker 0: Looking at my soda here. So let's so let's move on. I would love to know just, like, at a high level, in about 5 minutes ish, I would love to, like I I wanna absorb as much as I can in the 5. I'd love you to, like, show me stuff. Show\u003C/p>\u003Cp>Speaker 1: me stuff.\u003C/p>\u003Cp>Speaker 0: Could you maybe talk about some of these primitives and the structure? And I understand that there's this idea of, like, not everyone has the same role within a decentralized network, and I'd love to talk about that how it works. We when we briefly prepped for this, we spoke very briefly about this thing called, like, a consensus mechanism. Don't know what it is. If you could share that, that would be awesome.\u003C/p>\u003Cp>Speaker 1: Absolutely. So cut me off at any point because, you know, as you know me very well, I can be long winded in my in\u003C/p>\u003Cp>Speaker 0: my life. The timer?\u003C/p>\u003Cp>Speaker 1: I do see the timer, but you're not you're not gonna pay attention to the timer. I'm actually\u003C/p>\u003Cp>Speaker 0: You'll ignore it. That's my job. Fine.\u003C/p>\u003Cp>Speaker 1: A timer like Kevin. Yes. So, essentially, we had already mentioned briefly that the way this, works at a basic level is that data is replicated across all these individual servers and, you know, people's computers around the world, and those are called nodes. Right. And the question, of course, has to arise.\u003C/p>\u003Cp>What happens when there is a dispute amongst the nodes? What happens when node 1 and node 33 say, no, the data is actually node 1 says one way and node 33 says the other way? And before we even get to there, what is the data? So we talk about blockchains. Right?\u003C/p>\u003Cp>What is a blockchain? It's a chain of blocks. What is a block?\u003C/p>\u003Cp>Speaker 0: Wow. Thanks.\u003C/p>\u003Cp>Speaker 1: I I know. Right? Was that was that definitionally circular? What is a hand? It is something that displays the characteristics of a hand.\u003C/p>\u003Cp>What is a blockchain? It is a chain that has blocks in it. I know. I'm like it's we're mind blowingly like astute and wise in this in this episode. But essentially what is a block?\u003C/p>\u003Cp>A block is a defined discrete piece of data that contains different elements of of of things important to the chain. So it's going to contain a cryptographic hash of the transaction used oftentimes, using Merkle Tree cryptography. So a Merkle ized hash, whatever that means, that's gonna have the previous block, the hash of the previous block, meaning the previous defined set of data and its current data. So that's and then that becomes like a hash that again can get proven cryptographically between the nodes that this hash is valid. It's gonna have some metadata at the top of the block sort of on the version of the chain, you know, versioning, you know, like we're all familiar with semantic versioning, versioning of the chain, other kind of pieces of metadata, and some other bits and bobs is going to be in the block.\u003C/p>\u003Cp>And so that block gets then disseminated across the nodes for consensus, and that's where we get to consensus mechanism. And consensus has to happen fast, efficiently, and also has to happen securely. And that's a complicated, dilemma. How do you affect fast oh, and don't forget, obviously, it goes without saying decentralized. Right?\u003C/p>\u003Cp>So how do you affect a decentralized and crazily fast and secure consensus across nodes around the world? Right. Because you you need to ensure these things. So that's where the mechanisms come into place. And there's different consensus mechanisms, and they you can kind of imagine them on a spectrum of decentralization and and and centralization, right, to try and to try and grapple with these things.\u003C/p>\u003Cp>The the most famous one that often people are aware of is the Bitcoin model, which is proof of work, a proof of work consensus. Proof of work consensus basically requires the servers to solve very complex mathematical operations in order to validate the transaction and then create that new block. That is the least centralized. It is the most decentralized because it doesn't designate or delegate any any node. It's just whoever finishes the mathematical operation first gets to be the node that offers the validation proof that again again gets disseminated across all the other nodes Oh.\u003C/p>\u003Cp>For validation. But\u003C/p>\u003Cp>Speaker 0: Sorry. And by doing it first and providing the validation proof, you get more of the insight.\u003C/p>\u003Cp>Speaker 1: You get the reward. You get the reward.\u003C/p>\u003Cp>Speaker 0: So you're trying to get the in that model,\u003C/p>\u003Cp>Speaker 1: you're basically There you understand the incentivization model there.\u003C/p>\u003Cp>Speaker 0: And you burn the planet in that way because it's really computationally expensive, but you get like, and that's that model. But that isn't that's not universal. Every No.\u003C/p>\u003Cp>Speaker 1: No. No. That's not universal. And I I by the way, I think to understand a lot of this, one also needs to understand game theory and, the whole pursuit of game theory of, like, how do you incentivize players in a game to complete compete? Where do you find the equilibrium of players?\u003C/p>\u003Cp>Like, what in game theory, we call that the Nash equilibrium. Like, what is the perfect moment in a game where all players are playing their optimal moves, that's called the Nash equilibrium game theory. And there's a there's really interesting like economics and game theory and cryptography, like, a lot of stuff that goes into this, but that's not for here.\u003C/p>\u003Cp>Speaker 0: Beyond the scope. Yeah. Yeah.\u003C/p>\u003Cp>Speaker 1: That's for beyond the scope of this conversation. So that's called proof of work. The problem with proof of work is it's incredibly energy intensive, and it's destroying the world. Okay. So let's let's put that in a category.\u003C/p>\u003Cp>We don't wanna destroy the world. We kinda like this world. You know? It's got its problems, but it's a nice place to live. It's maybe our only place to live for the foreseeable future.\u003C/p>\u003Cp>We kinda wanna keep it going. I know Kevin, you got a couple kids. I have a couple kids who kinda want them to have a world to live on. It's a nice\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah. You\u003C/p>\u003Cp>Speaker 1: know, it's fine. Maybe we wanted to go. Okay. Yeah. So then the the the other model that is very popular, is called proof of stake.\u003C/p>\u003Cp>And so as opposed to proof of stake, proof as opposed to proof of work, proof of stake is essentially that, the node operators stake their token to validate. And the ones that stake more, as collateral tend to get chosen more to be the validator, and then they get more stake and they get more back as a reward. There's a variation of this called delegated proof of stake where also delegators can participate in this consensus mechanism and can choose. So I'll tell you that people, other people who are playing in this game can choose a node operator and say, I'm going to stake as well on that node operator and I'm gonna get a portion of the reward and the operator will get a portion of the reward. And so people get to choose operators.\u003C/p>\u003Cp>So the benefit of this is it's less energy intensive by far, dramatically less energy intensive by scale, extraordinary scale. It is clearly a little less decentralized, because right? For obvious reasons. But the energy intensive nature of it, the the fact that it doesn't really destroy the planet any more than any other web application destroys the planet, is is a good thing. Like, let's say that's an unreserved good.\u003C/p>\u003Cp>It's a good. Right. And there's other models as well that are even less decentralized. There's something called proof of authority where basically the chain chooses, through its however the chain chooses things, and that's a whole another conversation. But the chain chooses approved approved nodes to be the validators.\u003C/p>\u003Cp>And those are unapproved like an approved list of node operators that can validate. That is clearly not super decentralized, but it is obviously also much more fast. And and you could argue more secure because you've you have a defined list of vetted\u003C/p>\u003Cp>Speaker 0: As as long as those nodes are kept secure. But, sure, you're right.\u003C/p>\u003Cp>Speaker 1: As long as nodes are kept secure.\u003C/p>\u003Cp>Speaker 0: I'm kept. In this in this world of it, it has to be energy efficient, decentralized, secure, fast. It's like the all of these various models\u003C/p>\u003Cp>Speaker 1: It's like a trifecta of a dilemma. Yes. Exactly.\u003C/p>\u003Cp>Speaker 0: So so all of these all of these, you know, do it different ways, and I'm sure you build your applications on different\u003C/p>\u003Cp>Speaker 1: And you also need to have an element of fault tolerance for bad actors as well. Sure. And we call that the Byzantine general's dilemma. And if you ever heard of the Byzantine general's lemma. It doesn't it's not from blockchain, but it applies to blockchain.\u003C/p>\u003Cp>It's the have you heard of this, Kevin? No. No. So very briefly because this is actually quite fascinating. Let's say you are that it comes from, army met army terminology.\u003C/p>\u003Cp>You are the Byzantine army, right, and you are surrounding a city and you're, you are proceeding to invade the city. The only way to tell all the generals that are surrounding this quite large metropolis that it's time to go, like lunchtime, is by sending messengers to all the generals around the place. And you don't get feedback from the messengers whether the generals have accepted or not. You just have to assume that all the generals will then activate their whatever they call them in armies, brigades. I don't know what whatever the thing is.\u003C/p>\u003Cp>So you have to assume that a certain percentage of your generals, either by malintent or by incompetence, will not activate their brigades. And maybe they're traitors. Maybe they're just bad at their jobs. We don't know. So you have to have an element of tolerance for ineptitude or for maliciousness.\u003C/p>\u003Cp>And all of these systems have to have what we call technically the BFT, the Byzantine Fault Tolerance.\u003C/p>\u003Cp>Speaker 0: The twins' exhausting, but I get it.\u003C/p>\u003Cp>Speaker 1: It's really really interesting. It's really interesting from, like, a nerd perspective.\u003C/p>\u003Cp>Speaker 0: So so just to help me understand, because I really wanna jump into, like, if you could if we can maybe build a little dApp, decentralized app together if you're open to that. But do that. But but just to help me understand, just at the core, there are a few players here. There are the developers of a chain, but they they will inevitably participate in it. But those two things are not are not a given.\u003C/p>\u003Cp>Then you're in the participation of a chain. You have validators, and and they are they might be on an approved list. It might be whatever.\u003C/p>\u003Cp>Speaker 1: You have to Depending on the mechanism the chain is.\u003C/p>\u003Cp>Speaker 0: Depending on the mechanism, they will validate and and drive consensus on what the\u003C/p>\u003Cp>Speaker 1: And send and send those validated blocks and they'll send those validated blocks to all the other nodes\u003C/p>\u003Cp>Speaker 0: to That was my last question. And then nodes are generic whether you validate this or not, and then you have what I may just call users, standard nodes, not\u003C/p>\u003Cp>Speaker 1: There are differentiated nodes, and, yeah, that's what you're, I think, intimating at right now.\u003C/p>\u003Cp>Speaker 0: Yeah. But but but there is there's\u003C/p>\u003Cp>Speaker 1: there's what we call user. There's what we call full nodes, which are the ones that can validate and affirm and do all the operations of a chain. Sure. Then there's archival nodes, which as the name sounds, are there to preserve the history of the chain. And then there's things that we call light nodes or light clients, which participate in some of the operations of the chain but don't validate.\u003C/p>\u003Cp>And those are really helpful when you have low low infrastructure, like if you wanna have a mobile app participate or you wanna have a wallet a mobile wallet participate. It would\u003C/p>\u003Cp>Speaker 0: just be like users. I'm a consumer.\u003C/p>\u003Cp>Speaker 1: Basically users, and they would query full nodes for more data, but they themselves don't possess the entire history of the chain, and they don't participate in the full validation of a chain. And there's other nodes as well, but those are some of the big ones.\u003C/p>\u003Cp>Speaker 0: That's really interesting. And then just my final question, just to make sure I got it. When I I'm a user. I have a I run a light node, which could be a client, right, a web app, whatever, and I want to gain data. I'm not going to a specific node for that data.\u003C/p>\u003Cp>No. I'm asking the the chain. There is a mechanism for me to just go out and say, I would like the latest version of a thing. No. Because all the nodes should have the latest version.\u003C/p>\u003Cp>Speaker 1: So there's different ways there's different ways of doing that from the, application Velma perspective as well. Some chains can expose things like GraphQL API endpoints that allow you to query the chain through like a GraphQL API query. So from the web app developer, it doesn't feel any different than you're building any other app and you have to unfortunately use GraphQL and create very long verbose queries that you could just do with the REST API. But that's for another episode of yours. But so, so it doesn't feel any different from that perspective of a web developer.\u003C/p>\u003Cp>And then you would there's also the the archive nodes that could be used just to query for data. And so you're querying specifically to the archive node asking it for, you know, current state. That's another example, but often it's through, like, API endpoints that are exposed.\u003C/p>\u003Cp>Speaker 0: But then if I want to participate, that's the difference between a read only application and one that I can post a status to or something like that. And at that point, I'm no longer a light node. No. I I could be a light node.\u003C/p>\u003Cp>Speaker 1: Light node. Even when you're sending a transaction, you can still be a light node. It's not\u003C/p>\u003Cp>Speaker 0: gonna be validating it\u003C/p>\u003Cp>Speaker 1: right now. You won't be validating and, and unauthoring and participating in the authoring of that block. You'll be spending the transition transaction to the chain to be included in the next block, I. E. The next discrete data bit, but you won't be part of the affirmation process of that block.\u003C/p>\u003Cp>Speaker 0: So we have to summarize, and I know this is still a a a light version and a bridged version of reality. We have light nodes, which you can think of as just users of an application. They can query. They can send data in. Then you have, then you have full nodes, which are part of the they are they are basically the keepers of the chain.\u003C/p>\u003Cp>They will, based on some mechanism, decide what is what is true amongst themselves with some degree of fault tolerance call, and they generally will stake some kind of resource on their ability to do that accurately fast accurately and and correctly. And then you have archival nodes, which just store state, but they won't be part of that consensus mechanism. And there are various other kinds. These are these kind of big you I don't think primitives is the right way, but categories of these nodes. That makes lots of sense.\u003C/p>\u003Cp>I would love to see this in action, and I'm sure I will have loads more questions.\u003C/p>\u003Cp>Speaker 1: I love that we had this conversation, by the way, Kevin, just to reflect on it for a moment. I think what you're doing is so valuable because we all come to things with a lot of opinions, but to be able to gain just and most of us who are listening to this or watching this later, not all of us, but a lot of but many of us will come at it from some set of technical background and we approach things from a technical perspective. And so to be empowered more with the technical implementation details, it's not that it's to change one's opinion either which way, but to empower one in their opinion, to give them actually and maybe it does change your opinion. But, you know, we approach things through technicalities and through understanding technical specs. And so this conversation doesn't happen enough.\u003C/p>\u003Cp>So, really, I think it's a really, really good thing that we're doing this.\u003C/p>\u003Cp>Speaker 0: Thank you. And that's really the point of this series is I'm trying to put away the, you know, any negative, bias that I come with, and you're one of the people I trust most to come in and kinda just cut the idealistic vision piece, which a lot of folks\u003C/p>\u003Cp>Speaker 1: because I'm such a I'm such a pessimist realist.\u003C/p>\u003Cp>Speaker 0: Such a pessimist, but but I I knew I know that I can just pause you and go hang on. We're going on an idealistic train here. I and we haven't Good faith. Too much here, but, like, I just wanna know. I just have questions.\u003C/p>\u003Cp>Now I've already learned stuff. There was also some assumptions I had. I don't wanna kind of ruin where where I land with this, but, like, not every blockchain has to be tokenized. That is really interesting to me. So there is a technical nature of this where if characteristics are are correct for your use case, You can use this, and it doesn't have to be backed by by cryptocurrencies, which many see as scammy.\u003C/p>\u003Cp>And I will not pass comment on that in this moment. But those 2 those 2 worlds, they are not they are quite linked, but they are not inextricably linked. Like, they can exist.\u003C/p>\u003Cp>Speaker 1: One one could say I have evidence. I think this is an actually an accurate thing to say that cryptocurrencies are an articulation of a use case of blockchain, but in itself is not the totality of blockchain. It is by far one of the most and maybe the most prominent use case that's been developed to blockchain. And for obvious reasons, human nature, right? We as people tend to want to seek things that will improve our wealth standing and improve our, That's just how we are.\u003C/p>\u003Cp>And if we're being honest with ourselves as people, that is that is like baked in to to humanity. So that's it. It's not a surprise that new technologies often get articulated early on by those seeking profit first and foremost and maximizing profit. That is true with all new technologies that have ever been developed, including decentralized ledgers like blockchain.\u003C/p>\u003Cp>Speaker 0: But that isn't but I think what you've said in the reality are not the same thing there. Like, if crypto I I would love to get into the demo in a moment, but just to kind of, articulate my response to that, like, sure. I've heard loads of people in web 3 say cryptocurrency is but one use case. It is but one very common use case for it. However, it's until this conversation, I believed every other use case was built on top of that on top of cryptocurrency.\u003C/p>\u003Cp>Therefore, they are 1 in the same. It's not a use case that it is the fundamental piece that without this whole thing doesn't work. Well, that isn't the case. You\u003C/p>\u003Cp>Speaker 1: just have to flesh out the distinction between tokenization of incentive and cryptocurrency. Those are not exactly the same thing. That an internal system has a way to incentivize participation and using your resources and time and hardware is not the exact same thing as cryptocurrencies as a competitor to, you know, a government backed fiat currency. Right? Those are those are 2 interweaved, interwoven, whatever the correct grammar is there, but they but they're they are slightly different.\u003C/p>\u003Cp>Speaker 0: Yeah. Cool. Good to know. And then the other thing was just I think I just didn't understand enough about the tech, the characteristics. I'm starting to get that a little bit now.\u003C/p>\u003Cp>If you're able to, if you're willing to\u003C/p>\u003Cp>Speaker 1: Can we look at something together?\u003C/p>\u003Cp>Speaker 0: I would I would love that. I would love\u003C/p>\u003Cp>Speaker 1: that. Let me just see if, let's do this.\u003C/p>\u003Cp>Speaker 0: So I did ask you before this to maybe, like, prepare a little something. So I'd kinda be curious just to set the groundwork for for what we're gonna do. I'd love to know what we're gonna look at together and maybe just the background of, you know, there is gonna be some level of infrastructure already in place. We're not gonna go and set up, maybe we will, but we you know, this may be be built on top of some existing chain infrastruct the the wording, I'm not quite finding No.\u003C/p>\u003Cp>Speaker 1: I appreciate that because I think that'd be given the time constraints, we're not gonna build together on this on this, moment at this moment. But what we will do is walk through some of the code because just like what we did, now by demystifying some of the terminology of the technical specs and how it works from a technical layer, I think it's also equally important, and I think you agree on this, to also demystify some of the technical specs. And when we talk about decentralized applications or dApps, how is that actually different from any other kind of app that one may build? And, you know, the TLDR, by the way, is just not that different. It's quite similar.\u003C/p>\u003Cp>And, and honestly, from a design perspective, that was intentional because if we want to help people build, developers to build in a new space, do you create an entirely new way of doing things, or do you just build on top of the familiar patterns anyone has when they're building, let's just say a web app or a mobile app, right? So you're gonna do the exact same things and in many cases use either the exact same language stack or slightly modified domain specific versions of that language stack, And and, and this case is what we're gonna look at, and the latter is what we're gonna look at. So what we're gonna look at is very briefly a very small sample dApp, to essentially create your own personal micro journal or microblog that you can store your thoughts and only you can access your thoughts, and it's it's your kind of, like, personal remember they used to be these web apps. I forgot what they were called even. Maybe LiveJournal was one of them where you could publish your thoughts and remember that.\u003C/p>\u003Cp>Was it LiveJournal? It was LiveJournal. Right?\u003C/p>\u003Cp>Speaker 0: Yeah. It\u003C/p>\u003Cp>Speaker 1: was. And was LiveJournal gated, I. E, like, I can only see my own thoughts if I wanted to. Was that a setting? I think you could share it or you could you could make the setting that you don't.\u003C/p>\u003Cp>Right. Yeah. So kind of a similar idea, a scaled down version of that. And so if we look in the folder structure, what we see is actually 2 different folders. We see what's called here a blog contract as one folder and then the front end as the other folder.\u003C/p>\u003Cp>And, that's obvious that in our case of a dApp, the back end is called the contract. The back end is a smart contract, and I think it's not an exact one for one synonymous comparison, but it is a great simplification of it for our purposes that a smart contract is essentially a piece of executable code that lives on the chain, that lives on the blockchain, lives on a block that can be called to do things. So it's code that lives on chain. And the 1st blockchain to make programmable blockchain possible with smart contracts is Ethereum. Right?\u003C/p>\u003Cp>Before Ethereum was Bitcoin, Bitcoin was not a programmable blockchain. You cannot put smart contracts on it, but Ethereum was the first one to make that possible.\u003C/p>\u003Cp>Speaker 0: You put code in a block. It goes in the chain. All the validator nodes go, yeah. Cool. This is part of the chain now.\u003C/p>\u003Cp>And at any point, I can call the code that lives on the chain.\u003C/p>\u003Cp>Speaker 1: Yeah. So, actually, let me show you very briefly. Let me open up a code editor here. So if I No. I don't\u003C/p>\u003Cp>Speaker 0: want to bump up that font size.\u003C/p>\u003Cp>Speaker 1: No. But this is I will bump it up. I know. I just opened it. But, let's see.\u003C/p>\u003Cp>Where is it? Why is it not I'm not seeing it. Oh, it's in here maybe. Wait. Where am I missing it?\u003C/p>\u003Cp>My dot env. I don't know why I can't find it right now. Should be in there. Anyhoo. So Maybe it's oh, I know where it is.\u003C/p>\u003Cp>Sorry. See, this is real time. Right? There it is. So in the front end side, so in fact, the only thing I have in my dot end file is my contract ID.\u003C/p>\u003Cp>And what is my contract? I'm using a React. My front end revealed. It's a React app on the front end. Oh my god.\u003C/p>\u003Cp>The great reveal has been shared. But, what is and, you know, you preface, you know, your dot end variables in React with React app to make them available. Right? That's kind of the part of the architecture of React. So what's the contract ID?\u003C/p>\u003Cp>That is the address of my code on the chain. That's the that's the, the place, the location identifier of my code on the chain,\u003C/p>\u003Cp>Speaker 0: Which you don't\u003C/p>\u003Cp>Speaker 1: need to do\u003C/p>\u003Cp>Speaker 0: on the chain.\u003C/p>\u003Cp>Speaker 1: That's not private. Right? So I'm just using dotendvariables just for convenience, but this is my contract address for this contract. Right? So this is the the location on on this particular chain, whatever chain I'm\u003C/p>\u003Cp>Speaker 0: putting in. This is similar this is similar to, like, writing some code that has to be hosted on AWS. You have to deploy it to get the URL in order to call a serverless\u003C/p>\u003Cp>Speaker 1: serverless serverless serverless serverless\u003C/p>\u003Cp>Speaker 0: serverless serverless serverless serverless. This is the\u003C/p>\u003Cp>Speaker 1: equivalent of the URL. Exactly. And anyone could query this chain and see the contracts that are on this chain, anyone. And and look at this address and see the code that I've uploaded at this address through a query for a a block explorer.\u003C/p>\u003Cp>Speaker 0: Which is how you increase trust because anyone can Exactly. That's fine.\u003C/p>\u003Cp>Speaker 1: It's how you eliminate the need to have trust.\u003C/p>\u003Cp>Speaker 0: So, I mean, I think this is that might be idealistic semantics, but it's how you build trust. It's I can go look at it. Right?\u003C/p>\u003Cp>Speaker 1: It's how you label people to verify for themselves, basically. Right?\u003C/p>\u003Cp>Speaker 0: Sure.\u003C/p>\u003Cp>Speaker 1: So, okay, so we have these 2 folders. We're going to close the front end just for a minute just so we could walk through the back end, the contract, because I think that's a bit more interesting. So just by full disclosure, what you're going to see is one implementation of smart contract architecture. This is coming from the company I work at because why not? I work at Fuel.\u003C/p>\u003Cp>It's building an execution layer for Ethereum. So when I talk about an execution layer, I'm talking about and I'm gonna give you a 60 second synopsis of this because if I don't, it doesn't make any sense. When we talk about execution layer, we're talking about in the context of a modular architecture where you separated out the concerns like a separation of concerns, kind of like a models, views, controllers, MVC model, web framework, where you have the consensus layer and the execution layer as and there's another layer as well. I can't remember on top of my head, but someone will tell me in the comments, I'm sure, once this is out, and I'll look it up as soon as we're done, but the you separate out those concerns and there are different, parts of the different parts of the chain functioning in different ways and sharing the data between them to enable, basically higher throughput, right, higher speed. You you you have dedicated parts of the chain that do dedicated things in order to just, well, it's it's good.\u003C/p>\u003Cp>It's good architectural design, first of all, if you believe in like microservices, and it's also it just makes it more easier to debug when there's problems, and it increases increases throughput. Right? Some of the benefits. So we're building out an execution layer. Right?\u003C/p>\u003Cp>So as part of that developer centered kind of experience, we built out a DSL, a domain specific language for smart contracts called Sway. It's based on Rust, so it's it's Rust based DSL. So it looks a lot like Rust, but incorporates a lot of features that make it a lot more intuitive for smart contract design or more tailored to smart contract design. And so in that context, everything starts at a main file. And the main file, you can have 3 types of files, contract, which is the executable state full piece of code on the chain.\u003C/p>\u003Cp>You can also have a script, which is, can access state but is not stateful. Right. It's only state oh, actually, I take that back. It's stateful in the moment of when it's executed, but it doesn't hold state. It doesn't keep state.\u003C/p>\u003Cp>Speaker 0: Like a serverless function? Sure.\u003C/p>\u003Cp>Speaker 1: It's like a it is a serverless function. That's exactly what it is. Amazing. And the other, the other type of thing you could define here is a predicate, and predicates evaluate to true or false. They they don't hold state and they don't access state.\u003C/p>\u003Cp>They evaluate a a, a, they basically create a a Boolean evaluation. And if the thing evaluates a true or false, that can then call a transaction on a chain or it can call a thing to do something on the contract. So you could incorporate that kind of interface. You can incorporate that kind of functionality, I should say, in a smart contract. But to further round the separation of concerns, removing out that true or false, like, did I give you 50 tokens or not?\u003C/p>\u003Cp>If I gave you 50 tokens, do this. If I didn't, don't do that. So instead of having that as part of a contract interface, I take that out and I just make that its own little snippet of code that just checks whether this is true or it's false. And then if it's false, do y. If it's true, do x, and that's essentially it.\u003C/p>\u003Cp>So that's the 3rd type, of of code you can have, contract script or predicate.\u003C/p>\u003Cp>Speaker 0: Can I ask\u003C/p>\u003Cp>Speaker 1: one quick question quickly? Of course.\u003C/p>\u003Cp>Speaker 0: So we've got 2 parts. We've got front end, which will just run-in a browser that can be hosted on AWS or Netlify\u003C/p>\u003Cp>Speaker 1: or Or Vercel or Netlify.\u003C/p>\u003Cp>Speaker 0: And we have the back end. I understand it's not a a straight one for 1, but the executable code that will touch state and the rest of the chain, the database in the it's not quite that, but whatever. And that is that lives on the chain. I'm one thing I'm not really getting is when does the user of the React app, like, have to provide token to participate? Like, what part what part of this does this touch a a store of token?\u003C/p>\u003Cp>Speaker 1: They may or may not ever need to touch token. It just will depend on the design and the decisions of the particular application developer and what they want to build. So if they wanna build something that requires the user to pay for things or then they would need to provide some token. If you don't want to build something like this small sample application, which I'll run-in a moment, you can see it, it doesn't require any any token because there's nothing it requires an account. It requires a wallet address because that wallet address becomes your identity, but it doesn't require any token.\u003C/p>\u003Cp>If you want to build something that is you know, a marketplace, I think you would probably wanna have token. If you don't wanna build a marketplace, you don't you're not building a trading platform or a lending platform or any of those kind of things, then you don't you don't need to have token. If you want to pay for the cost of querying the chain because, you know, that has cost to it because you're using people's infrastructure, then you as the application developer can cover that cost. And maybe you have other revenue models for your application. Maybe it's through advertising.\u003C/p>\u003Cp>Maybe it's through, all the other ways app developers in any in any web space get revenue. Right? Like, it doesn't have to be through the user.\u003C/p>\u003Cp>Speaker 0: I think you answered it. I might just dig what a little more you said. If the application owner wants to pay for the I forgot the exact wording you said. I'm a little bit confused. This is being hosted on a block on an Ethereum blockchain.\u003C/p>\u003Cp>Speaker 1: It's being hosted on a fuel on the fuel testnet.\u003C/p>\u003Cp>Speaker 0: Right. And that is\u003C/p>\u003Cp>Speaker 1: We're not yet to, like, production main status on\u003C/p>\u003Cp>Speaker 0: deployment of this block, the submitting this this executable this smart contract, that would cost some money. And then to query it would cost some\u003C/p>\u003Cp>Speaker 1: So when I right. So when I would publish a new journal entry, that's putting data into the next block that will be finalized, which costs money, infrastructure. It's infrastructure costs infrastructure cost. That is equivalent of AWS cost or the equivalent of AWS\u003C/p>\u003Cp>Speaker 0: I'm not I'm not against it. I'm not trying to be like, oh, you have have to pay for it. I'm for pay people for for infrastructure. I was just trying to understand what, where, how\u003C/p>\u003Cp>Speaker 1: And so you as an application developer can choose how you, you know, build your cost models and your revenue.\u003C/p>\u003Cp>Speaker 0: Wallet addresses their ID, so that is kinda how this all hooks into it's like log in with PayPal. You know? Yes.\u003C/p>\u003Cp>Speaker 1: So exactly. So There's\u003C/p>\u003Cp>Speaker 0: a wallet there with money in it.\u003C/p>\u003Cp>Speaker 1: In the other in the more, you know, in the prevalent kind of web 2 models, login is done with login and password or login with username password or login with social accounts. In the web 3 model, login is done with your account, your wallet account, your ID. And that's an immutable address that links you across, you know, the network, and, and you can use it in any way you want. Many people have many different wallet accounts for different things. Right?\u003C/p>\u003Cp>So I may have a wallet account that I keep in a place that's very hard to access online and I where I may keep more of my funds. I may have a wallet account I use for debugging and, like, testing things when I'm building applications and many of those. I may have one I use for, like, common, you know, web apps where I'm using, you know, the very popular Chrome extension called MetaMask or a browser extension to enter, and I don't want to, like, put a lot of sensitive data with it. So I may just use that for, like, you know, social apps where it's requiring me to log on. And there's all different sorts of addresses you use, but the address becomes your login.\u003C/p>\u003Cp>Speaker 0: Got it. So they're inextricably linked in this setup. Again, these tokenless tokenless blockchains are completely separate from this. It's a different implementation of the same concept. So I'm sorry for interrupting you.\u003C/p>\u003Cp>I just felt that was really important.\u003C/p>\u003Cp>Speaker 1: No. It's an important thing.\u003C/p>\u003Cp>Speaker 0: And so should run us through. Yeah.\u003C/p>\u003Cp>Speaker 1: Yeah. So just to very very briefly run through. So this is essentially a lot of Rust syntax, so it looks a bit like Rust, but if, but with any Rust developer would see differences. But here I'm including some modules and because I separate out the concerns, I have a module I created for my data structure. I have a module I created for my interface, meaning, you know, so I have down here an implementation block and this sounds familiar to a lot of different languages as well.\u003C/p>\u003Cp>So I have an interface that defines what my code will look like and what each thing returns. And then I have an impl block for the actual implementation of that interface. Right? So if I go to the interface and it's in a file called interface, look at that. If I go to my interface, I see this is a library.\u003C/p>\u003Cp>Right? This is not a contract. It's the library. And I'm using my data structure of a post, which we can look at in just a second, and I'm also using from the standard, Rust library, vector, storage vector, a data type, right, kind of like an array, and here is my interface, my where I define what a blog is, what is inside a blog. It has a post function.\u003C/p>\u003Cp>It has a get post by author function, initialize user function, a get number of posts function, and a get post, and each one of them returns a different thing. This returns a vector of posts. This returns an identity of a user, which is a type. Right? That's a class.\u003C/p>\u003Cp>This returns a unsigned 64 bit integer of getting number of posts and this returns a post. When I get a post, it returns a post. What is a post? A post is this. And where I define posts?\u003C/p>\u003Cp>In the post file. I love it's simple. From okay. You know, my background, by the way, Kevin, is I was a for a long time a Ruby on Rails developer. And we have to get back to that, right?\u003C/p>\u003Cp>Because one of the things I love about Ruby on Rails is the convention over configuration and that things live in certain defined places. And one of the things I find most frustrating for myself personally, just speaking personally, in the JavaScript framework landscape is the lack of convention. And I love frameworks like Vue, for example, that start imposing a bit of convention. And so I can go into a Vue a lot of Vue web apps and I start understanding you introduced me to Vue, and I'm grateful for you to you for that because I can go into Vue and I can at most web apps and get a sense of the land fairly quickly. With rails, that happens instantaneously because of conventional reconfiguration.\u003C/p>\u003Cp>So this kind of convention makes me very happy. So I go into the post data structure, and this is another library. Right? And I have my struct, which is kind of like, a class in Rust. I have my struct for a post, which has 3 types, 3 fields, an ID, an unsigned, 64 integer, a content type, which equals a string of 280 characters, and an author, which is an identity.\u003C/p>\u003Cp>And then I have an implementation of my post where I can create a new post. This is like a class method. Right? Create a new post. And it returns back the self containing an object of ID, the content, and the author.\u003C/p>\u003Cp>So that's now getting back to main. So I have I've included these two things in my main, which is the main interface for the applications, the call point. It's like the app dot JS or what have you. And then I'm saying I want to use all these different libraries. I want to use a hash.\u003C/p>\u003Cp>I want to use a vector, etc. I want to use my post data structure. I want to use my blog interface that I define. And then I have a storage. This is what it will be go into my block.\u003C/p>\u003Cp>This is what gets published in the block. What gets published in the block are the posts, the number of posts, and the user. And so the post is a map of key value, the key being a number and the post. The number of posts is just a number, and the user is an as an identity. And using option, which is, you know, oh, helpful, helpful,\u003C/p>\u003Cp>Speaker 0: Type that represents an optional value.\u003C/p>\u003Cp>Speaker 1: Right? It's an at an enum that represents an optional value, either some or none. So I default it to none, and then I provide it with it. And then basically the rest of it is kind of standard Rust code. So, this is meta programming in Rust.\u003C/p>\u003Cp>This actually goes if you would dive into the Sway code base, you'll find, like, hundreds of lines of code defining what this is. But this is Rust uses a lot of meta programming or you can use a lot of meta programming in Rust to define macros. So these macros, like, abstract away a lot of the things, so I just have to write my actual logic. And then this is, like, create a post. This is get a post, and this is initialize a user and etcetera.\u003C/p>\u003Cp>And then that's basically the back end. Does that feel dramatically different? Obviously, it's not JavaScript or TypeScript. It's Rust, but does it feel dramatically different to you?\u003C/p>\u003Cp>Speaker 0: No. Not particularly. I'd be interested in the intricacy where it starts to involve token, but, like, no. Not on the surface. And this these are, as you say, the primitives.\u003C/p>\u003Cp>Can we see the front end briefly? We're we're starting to we're starting to run on both of our times.\u003C/p>\u003Cp>Speaker 1: Very, very briefly. So the front end,\u003C/p>\u003Cp>Speaker 0: essentially Even just the API calls would be interesting.\u003C/p>\u003Cp>Speaker 1: Yeah. So let's go to, the so first of all, it's TypeScript. It's a React app with TypeScript, and we then generated a lot of different type generate a lot of types for the front end to interact with the back end. Right? And so if we look at the front end, well, that's the index file.\u003C/p>\u003Cp>That's not so interesting. But if we look if we look here, we're using we're basically using the the, we have a, a wallet SDK for TypeScript, and React libraries within it, and that allows us to basically, you know, abstract away a lot of that concern as well. So we're importing useAccount, use connect, use wallet, use is connected. These are different, like, what's the fancy word for it in React? But different, like, state, verifiers.\u003C/p>\u003Cp>Right? So, like, if I go\u003C/p>\u003Cp>Speaker 0: sounds plausible.\u003C/p>\u003Cp>Speaker 1: That is but it's not it's not the term in React. We know that. But I'm not a React developer. I barely can write React, essentially.\u003C/p>\u003Cp>Speaker 0: Neither am I. You told me I taught you Vue, and then immediately, here's the React app.\u003C/p>\u003Cp>Speaker 1: I know. What can I say? I what can you do? So, you know, we're basically defining the different state of the app. Right?\u003C/p>\u003Cp>So, is connected, uses that, connect, yada yada yada yada. And then we create posts. We use state. We create a post as an empty array. New post content is a string, etcetera.\u003C/p>\u003Cp>We define a type for post output, with different, you know, parameters and their types, and a type for a post, and then we set the wallet address. So once we set the wallet address, if I was building an application with tokenization as part of it, then I could also do things like request payment. I could request to pay. I could send token, and I could do all that sort of stuff. I'm I'm not doing any of that here.\u003C/p>\u003Cp>I'm just getting the wallet address for the contract from the person. And then the rest of it will kind of look similar to another any other React app. I define some some functions like get posts, and then, you know, like, the checks, like, if there's a value, if there's not a value, right, I wanna catch that and put a console in the log. Like, it's not that's kind of standard JavaScript React programming or TypeScript in this case. And then down here is the actual front end\u003C/p>\u003Cp>Speaker 0: Sure.\u003C/p>\u003Cp>Speaker 1: Kind of standard. So if we run this, so let me go into the front end. Now if I can type. Thank you.\u003C/p>\u003Cp>Speaker 0: It's fair. It's what I write most times.\u003C/p>\u003Cp>Speaker 1: I so appreciate that.\u003C/p>\u003Cp>Speaker 0: Set up an alias.\u003C/p>\u003Cp>Speaker 1: I should alias it as well because it's even in there. Look at that. Nom, was there for a second. Alright. So npm start, and it's gonna\u003C/p>\u003Cp>Speaker 0: pop up. Look it doesn't look that different if you were just using any kind of authentication service plus a payment service, I guess.\u003C/p>\u003Cp>Speaker 1: So this is, like, my this is my my little blog. Right? Like, this is exactly what it looks like, and there's no post in there currently, but I could write a post. Let's see if this works. It may not work, but let's see because I haven't played with it in a while.\u003C/p>\u003Cp>But we're live. This is fun. This is a post of mine. And, of course, it's not working right now. Because that's the that's the law.\u003C/p>\u003Cp>That's the law of things.\u003C/p>\u003Cp>Speaker 0: We don't need to work it out. In theory, that then gets submitted as a block on the chain.\u003C/p>\u003Cp>Speaker 1: In theory, it gets submitted as a block on the chain. I do not know why it did not work, but it did not work. Oh, there we go. Thank you. Now it's working.\u003C/p>\u003Cp>I don't know why it didn't work before. I think I was making changes. I didn't save it, the file.\u003C/p>\u003Cp>Speaker 0: That was\u003C/p>\u003Cp>Speaker 1: the that was very basic. So here you see it prompted already because I have 2 wallet extensions loaded. So it's asked me which wallet I want to connect with. Right? So initially, I've these are just 2 different wallets in our ecosystem, and I play with both of them.\u003C/p>\u003Cp>So I'm going to connect with this wallet. Why isn't it\u003C/p>\u003Cp>Speaker 0: Is it the fact that you're in this little mini arc thing? Oh, no. Popped up another one.\u003C/p>\u003Cp>Speaker 1: So I'm connecting. Right? And it's saying, okay. You wanna connect to this application on local host. It wants it can view your balance and activity and then and can request approval for transaction.\u003C/p>\u003Cp>Speaker 0: Like an OAuth flow.\u003C/p>\u003Cp>Speaker 1: Yeah. Right. So I'm gonna connect.\u003C/p>\u003Cp>Speaker 0: I'm sure that isn't the mechanism of that. That's Oh,\u003C/p>\u003Cp>Speaker 1: why is it not working, Kevin? Nothing ever works when you want it to work in real time. Oh, now it's working.\u003C/p>\u003Cp>Speaker 0: Yay. It's all good. It's all good. I mean, a lot of this is about illustration rather than, like, oh, I click So\u003C/p>\u003Cp>Speaker 1: here you see my post, and let's see if I create a new post. This is a new post. Beautiful. Okay. Approve.\u003C/p>\u003Cp>Speaker 0: Approve transaction because that's what's happening here. You're providing token even if it's is a text And\u003C/p>\u003Cp>Speaker 1: there it is. This is a new post.\u003C/p>\u003Cp>Speaker 0: And there it is. Interesting. Yeah. I mean, that's the case on the front end. It doesn't feel terribly different to This\u003C/p>\u003Cp>Speaker 1: is why, by the way, I tell all my DevRel colleagues to always record their live coding for presentations and not do live coding from the state.\u003C/p>\u003Cp>Speaker 0: Not. I think the wealth of knowledge that I have gained as a result of talking to you today transcends the fact that you pressed the button and and something\u003C/p>\u003Cp>Speaker 1: didn't change. And by the way, the way this would start is actually quite easy. So, you know, you have, create react app, right, in the react land. If I wanna create a new contract, so we have a tool called fork, which is the fuel orchestrator, and I would just do fork new and the name of the contract and instantiate an entirely new contract for me. So fork new blog contract.\u003C/p>\u003Cp>Speaker 0: Which which, just to be clear, is the local code required to write it. That would still need deploying. That would still need submitting Right.\u003C/p>\u003Cp>Speaker 1: So let's let's get out of this for a second and see what that looks like. So fork new sample contract. And then if I go to sample contract and I take a look at it, it's very small. There's nothing in there.\u003C/p>\u003Cp>Speaker 0: So so\u003C/p>\u003Cp>Speaker 1: It just here's my AB. And you see it's not even separated out. So that can be\u003C/p>\u003Cp>Speaker 0: that can be deployed. That could be\u003C/p>\u003Cp>Speaker 1: That could be deployed. It's just a contract that returns a boolean of true, and it'll always be true. Right? There's not there's no operation happening. It's always gonna be true.\u003C/p>\u003Cp>Speaker 0: It's really interesting. So that's I suppose I suppose a lot of the complexity here is abstracted away by helper libraries It provided by fuel my guests, which is really interesting, all the ecosystem writ large. But, thank you. That was that was a great episode of learning things I love to hate. I hope that that was that was good for you.\u003C/p>\u003Cp>I feel like I hopefully didn't ask too many really difficult questions, but the questions I did ask allowed\u003C/p>\u003Cp>Speaker 1: Kevin, anyone who knows you knows you are a wonderful person, and anything you ask is fantastic. I think this is a very good conversation. Thank you for inviting me.\u003C/p>\u003Cp>Speaker 0: Thank you for being part of it, and thank you everyone for watching this. Until next time. This has been learning things I love to hate. Bye for now.\u003C/p>","Hello. My name's Kevin, and welcome to Learning Things I Love to Hate. The goal of this show is to go into situations with an open mind and learn more about the tech behind the hype. And in this episode, I'm joined by my dear friend, Ben Greenberg. Hello, Ben. Hello, Kevin. How are you doing today? I am doing really well. How are you? I'm fantastic for speaking to you. The topic of today is about web 3. There are so many realms of web 3, but because I don't know much about it at all, I thought let's start with a pretty generalist view. But before we jump into that, could you tell us a little bit about yourself, where you work, and just why why we're speaking about this topic. Yeah. Absolutely. So, Kevin, it is so great to be joining you on this. We've known each other for quite a while, and it's such a pleasure to be always in conversation with you. So I am the head of DevRel at a company called Fuel, Fuel Labs. We are building the fastest execution layer on Ethereum, and we offer a really developer centric, platform with a set of developer tools focused primarily on the ability to build decentralized applications, dApps, as one might wanna call them, in the blockchain space and to be offering, really performant and intuitive and developer facing, developer forward, Outlook for developers to build, whatever they're looking to build and to get going in in the space. So I don't understand some of those words. I don't know what an execution layer is. I'm sure we'll talk about that in a bit. But given that I don't know much about web 3, and I imagine quite a lot of the people watching this might be joining me, I thought we should start with this primer. And I thought a good way to start this is just a a real, like, candid point of just sharing some of my skepticisms that maybe we can address throughout this period we're chatting. If If we don't get to all of them, that's cool. But just at kind of a high level, the idea, the promise of decentralization, I think, is promising. And I think many people viewing will think, yes. Of course, that's promising in a world where large companies control large swaths of our data. But it always seems rooted in some kind of cryptocurrency, and I can't, in my mind, kind of sever and understand the difference between web 3 and decentralization and cryptocurrencies or tokens or something rooted in an area of tech that often is associated with scams. So maybe we can talk a bit about that because I I imagine it isn't all just one big, you know, interchangeable blob. And, also, I just don't get it. I don't know how how better way to say it. Like, if we just zoom in and look at the tech and forget all of the, like, idealistic, you know, backing of of why they exist, I don't really understand the characteristics of a web 3 application or a a dApp, and why they're unique and interesting. So I figured we might start by talking a bit about that, and then, we can get into some codes and maybe you can show me a little bit around. That sounds lovely. So where should we start, Kevin? You you you lead us on this journey. I think I kinda have these 2 main skepticisms. 1 around, decentralization and blockchain and cryptocurrency and kind of maybe just not even addressing the skepticism necessarily directly first at least, but what are the differences between these? That would be good. And then maybe talking about then we can jump into more more of the, like, technical, talking about what are the characteristics, like, how does it work at a high level, and then maybe we can jump into a demo. Does that work? That sounds perfectly fine. So first of all, just a bit of background on my, involvement in this space. So I only came into web 3 blockchain, working in it professionally about a year and a half ago or so, and I too was incredibly skeptical for a very long period of time. And I actually think I remain still a bit of a skeptic on a lot of it, and I think that perspective is actually incredibly valuable when you're working in any space, regardless of whether it's blockchain or microservice architecture or, you know, you're working on Kubernetes clusters. It doesn't really matter what it is as long as you kind of have and retain that element of healthy, constructive criticism and skepticism, I think that just benefits your work and sort of everything you're going forward on. And so I empathize with you and I share a lot of that same sense of unsureness or like, what the what the heck is this? So having said that, I think for me, one of the ways that I've synthesized understanding what we're doing here is my involvement back in, like, connected networking, pre web kind of goes back to the early nineties, and I used to run something back when I was a kid. I'm not that old, but I used to run something back when I was a kid, and I begged my parents back then to get me a few phone lines to make this possible, but it was called the bulletin board system at BBS. And I don't know if you remember or even heard of BBS's. Kevin, you're so young. You don't know these things. I don't wanna age you. I don't wanna necessarily make you feel too. Let's let's talk about BBS's for a minute. So BBS is where these, like, pre web places online where people could dial in and there were shared discussion forums. There were file servers. You could share data. It might take you on a, you know, 24 ks modem, you know, an entire day to download something. There were, you know, text based role playing games where you had 2 or 3 turns a day. And that was my introduction to, I guess, what one might call the online community was through BBS. I used to run run-in San Diego where I'm from, born and raised, called the Freethinker BBS. That was my BBS. I was that kind of kid back in the days. And, and then the web came. Right? And, and the web began in the kind of the same modality where it was kind of run by people in their homes or, you know, local. You would you would have a web server on your running on your 48680 megahertz PC, in your basement somewhere, and you'd be serving websites on an Apache web server, you know, on your 486. And then, of course, things dramatically shift. We don't go through the whole history of the web. But, we got to a point where we are now where everything is essentially running on AWS. AWS is running AWS in every other service you're probably ever going to access is somehow connected to AWS. And I think part of what the premise of what we're what we're working on in this space is how can we get back to a place where people own more of their data, where people own more of the, access their data and you have more familiarity and a sense of confidence and where things live. And there's more of a communal aspect to everything we're trying to do. And so I think that is like at writ large from a balcony perspective, kind of like the idea. That's the idea. And the way that it's it's run-in a blockchain context is so one of the first questions people always ask, and I think it's a really good question, is that so I'm accessing some blockchain application. Where the where is the data? Like, where is that actual data living? You know? So if I know if I go to, you know, x slash Twitter or I go to, you know, Instagram or I go to any of these places, I have a general idea from a web developer where the data is. But where is the data on any kind of decentralized application? And the honest answer is that data is everywhere. The data is replicated and duplicated on people's computers and on organizations around the world, at all times. So that spread of the data is, I think, the first thing that we want to tackle and address, and then we can get to other parts as well. But I think understanding that is a fundamental premise to understanding everything else that the data is not owned in any central server or any central node. It's actually spread across, multiple, potentially countless nodes. Obviously, not countless. Nothing is infinite. But yes. Sorry? No. Could I pause you for a moment and go back a couple of sec? Yeah. Definitely not. Sorry. The end. It's a it's a it's a train. We ain't stopping. So okay. So Okay. We'll take a break. We're at the trade station. Let me get it done. So on that train of thought, and I wanna come back to this train of thought, I wanna talk about the how does it work, right, and what are these nodes, how does the decentralization work, how can you trust it and so on and so forth? Can we take one step back? And I'm kinda curious again. What is the relationship between decent and maybe maybe you're like, no. Actually, we need to tackle them this way around for it to make sense. But I'm curious. What is the relationship between decentralized apps, cryptocurrency slash token slash some kind of fiscal value item and blockchain. And you you might just be like, of course, it's obvious, but, like, I really need to start thinking about it. Rule of anything is to never assume that anything is obvious. And I think that's like the first lesson we help teach people writing documentation, technical documentation. Right. Don't ever assume what is obvious to you is obvious to others. So to answer that question, I think you actually need to unpack a little bit more. And you need to you need to kind of further accentuate the issues. So considering that the the entire enterprise rests on the notion that people will choose to run these nodes, these data warehouses that replicate the data across the world. So assume people are going to do that. That's the assumption. Then you baked into that assumption has to be some kind of incentivization model for how one does that. And unless you operate on a fully altruistic model of being where I will voluntarily give my, I will voluntarily give my my electricity costs and my Internet costs and and my hardware costs, and I'm just gonna do this for the betterment of humanity, which I think you you and I, of course, operate in that level. Everyone else, I mean, we don't really know. Yeah. But, you know, obviously, we work for our companies entirely altruistically. Then you have to do some kind of incentivization model baked into it. So I think that's the first layer. And then you may say to yourself, okay, that sounds all well and good, Ben, But why can't that incentivization model be based on euros or pounds or dollars or Canadian dollars or pesos or any other form of currency? Why why does it have to be a digital kind of currency? And I think to answer that question, you have to then make that question larger. What is the value of any digital collectible or digital good that exists in any way, shape, and form from the gaming enterprises and beyond. So for example, I have a couple sons. One of them, he's, you know, fast becoming a teenager, is really into this game called Fortnite. I didn't know Fortnite existed until he got into it. That's how much, you know, you know, how how much of a dad I am. But he got he's really into Fortnite. And there's these, like, digital collectibles and things you can do in Fortnite that are really valuable to him. Why is that valuable? It itself is not, doesn't hold intrinsic value. I mean, we could also argue that a US dollar doesn't hold intrinsic value by itself. It's representation of value, but he finds value in it. So then I think the question becomes, if you're building this system and you want it to be digital first, so maybe you ought to create the incentivization model also grounded in a digital value and a digital collectible, a digital good. So then that's the second the second layer. And the third layer is, okay, Ben, what about cryptocurrencies? And to that layer, because then you're now extrapolating to, okay, now it's value transcends the incentivization model of of hardware storage and, you know, incentivizing me to run a node, etc. Now it's suddenly a competing currency in the in the world competing against, you know, global government backed currencies. And to that question, Kevin, I'm gonna say I don't want to get into that because I am not a cryptocurrency person. Like that's not what interests me, I would say, in this space. It's not what motivates me. And I do think and I will end this little bit with a little bit of a caveat, there is a bit of a privilege to not be a cryptocurrency enthusiast in this space. For example, when I travel to parts of the world where the governments are less stable and the currency is less reliable, there is a, there is a deference, to cryptocurrency that I am unfamiliar with as someone who has only lived in first world global north countries. And I am and I was actually a bit taken by surprise by that, and that just reveals sort of the the the places that I've spent most of my life living in. But, you know, the the there are places I've been where the the first question is asked to pay for something, what's your wallet address? So At a store. Interesting. The I don't I don't necessarily wanna go down the, like, and this is why cryptocurrency is a valuable track, which is, like, where this this area is going. But alright. So there's one question I have that I can't quite unpack yet, which is okay. To have people participate and participate, my understanding is there's, like, various degrees to participation, in a decentralized network, I suppose. You might correct me on my terminology by decentralized network or whatever. There's some kind of incentive. And, okay, your son gets Fortnite. Whatever it whatever he gets. Yeah. Sure. They don't have real world value. I mean, they possibly do. I think that is a whole marketplace, but whatever. You know, I think in digital games in general, those things have quite a lot of value. But let's assume let's assume they don't, and it's just I want I I want to give you something to participate. Actually, I'm going too far off the the end. Let me just ask the direct question. To to be involved in these networks, does it have to have be backed by some degree of, like, cryptocurrency token or something that converts into real money? For example, you were talking about I have sir a server in the basement, and it's running something, and that's great. And, you know, the web is weird, and we all host our own stuff. Now it's all hosted on, like, 20 data centers around the world, and now we'd like to go back to that. But, perhaps at that point in time, people were just hosting stuff altruistically. If I want people to participate in a decentralized thing that I build, why why is there a financial backing to or is there? Can can I just I'm gonna use some words perhaps ignorantly, stake some token for that has no real that isn't backed by anything that has real money. It's just a number of a thing that just exists. It just bites in the in the world, and that's that or does it always eventually get backed by one of these primitives that get traded? Yeah. I think well, to there's a couple of different questions in that. But I think, first of all so there's, you know, obviously, I began this our conversation with a bit of nostalgia back to the BBS world. And the thing that I don't have nostalgia about in the BBS world is how far we've come and what one can accomplish with the modern web and the modern Internet infrastructure. And I don't think any of us I'm actually going to take that back. I don't. There are probably people out in the world who do, but I don't want to go back to a world of, you know, 48 ks, 24 ks modems. And I like the conveniences that are wrapped up into my phone into the ability to do the things that we do on on a daily basis. I happen to enjoy that. But that kind and I rely upon it. I more than enjoy upon I rely upon it. But that kind of sophisticated infrastructure requires a lot more than, you know, the the 486 80 megahertz p Intel PCs that, you know, that we used to run things on back in the day. Oh, we. Yeah. Yeah. The we. The we. The we. And so I think the infrastructure needs are a lot greater than they were back then. And so even if it was the case that there was a that you could assume a level of altruism, today you have to you have to compensate people for their, for their costs. And then the second layer in that question is, well, what about a translation at some point to a real world value of the incentivization token and tokenization? Like, does it ever have to does it always have to translate back to a real world value? You know, I don't really know. And I'm going to defer to other people who probably will comment in the comments on this or offer their own perspectives. I don't really know if a this is a philosophical question. Right? Do if something is valuable inside a system, does it also have to be able to translate to value external from that is external to the system? And and what are the bridges that one needs to create to create that kind of synchronicity of value from inside a system to outside a system? You know, for I mean, I don't know about you, but I and I but I know for myself, I remember I'm a member of communities where there are value things there are things that are valuable that we do in those communities that are not valuable outside those communities, levels of, communal participation, levels of voluntary service, actions we do as part of, you know, social and ethnic and sub communities in the world that don't translate to value outside of themselves. But do I need to have bridges to show that value, externalize that value, and and translate the value to a larger the larger community, you know, that we live in, whether it's in in the United States or in Germany or anywhere. And, you know, that's, like, that's a philosophical question. Right? That's a larger question. I think in the case of of blockchain tokenization, the answer has been demonstratively yes because they have built those bridges to to convert the token that is used as an incentivization model to US dollar or to euro or to I think what I'm just thinking is if I wanted to host it and once again, I I wanna, I want us to move on a little bit in a moment, but maybe just for one more, like, quick quick bit here. But, like, if I just wanted to host a thing for me and my mates and this idea of it's decentralized just among us just among us, this is all cool. You know, there's, like, you know, 20 of us. Maybe it's like a school hacker club, whatever. And money doesn't need to be moving hands here. We're happy to spend some resources and not be reimbursed for them. It feels like just doing that is intrinsically wrapped up in a cryptocurrency of some kind. Even if it's small value, even if it's, like, not very much at all, it always from what I'm understanding, you can tell me no, actually. I'm not sure that's true, and it just happens to be true in most cases. It seems like it always ends up back in the world of Ethereum or Bitcoin or insert other I don't only know those 2. I'm sure there are. I think that I don't think that's true. I think that, if you don't require an incentivization model to to help, inspire people, motivate people, get them involved, then I think you can build your socialist utopia and and everyone can donate their resources as they as they choose and donate their time and their hardware and their costs. And that's entire and that works to some scale. It doesn't work. I don't think I don't think it's been proven to to work at a scale that can power something that is trans transnational that Sure, sure, sure. But that's much bigger. I'm just talking about, like, in theory, the concepts I'm about to we're about to talk about. Can create tokenless blockchain, of course. Yeah. A 100%. I mean, there there was no of course. I had no idea. I always thought there is no world in which that would, like, technically works, but it is. It just why would you slash? It's not very common, you know, or whatever. It only works as And and and, actually caveat. Fascinatingly, there are private companies that have you and we'll maybe we'll get to this in a little bit, but there are private companies that have built blockchain networks internally that are not, we would call, decentralized, but they're using the primitives of blockchain. They're using blockchain in order for things like provenance, tracking, inventory tracking, things like that. And they're not using it with token because it's all within their system. It's employees using the thing that the incentivization in the company is the is the salary and the stock options. Yeah. And they're using blockchain for the for the utility of inventory tracking, let's say. So the utility is what I the utility and the kind of these primitives and the structure, I'd love to talk about it. We're we're bumping up on you know, we're starting we've done about 20 minutes. We're bumping. We're talking. We're getting everything. Lots, that of already some of my assumptions have been dismantled, which is good. You know, that's that's why I invited you here. I wanted to genuinely learn more. There is I'd love to move on to a demo soon. But before we do that, maybe in, like, 5 ish You like my big Stanley Cup, by the way? This is the new rage in the United States. Everyone has these huge Stanley Cup now. Some of my friends got them. You know? Some people would call them quite basic. 40 ounces. But you know what they're gonna do, though? This is 40 ounces of water. I've seen Starbucks have just come out with, like, a Christmassy one. I'm gonna date this video and the the time we're recording. Yes. I know. You just did that. That's a bit of a problem. It's this this lovely red, like, you you know, matte red one. Yeah. That's nice. Yeah. But they only sell it in the US as well. Because we Americans, we really hydrate quite a lot, I guess, opposed to the Europeans. What was that type of trash? Ice. Right? The Europeans don't like to drink water as much as Americans do, apparently. There was a whole social media trend there. Looking at my soda here. So let's so let's move on. I would love to know just, like, at a high level, in about 5 minutes ish, I would love to, like I I wanna absorb as much as I can in the 5. I'd love you to, like, show me stuff. Show me stuff. Could you maybe talk about some of these primitives and the structure? And I understand that there's this idea of, like, not everyone has the same role within a decentralized network, and I'd love to talk about that how it works. We when we briefly prepped for this, we spoke very briefly about this thing called, like, a consensus mechanism. Don't know what it is. If you could share that, that would be awesome. Absolutely. So cut me off at any point because, you know, as you know me very well, I can be long winded in my in my life. The timer? I do see the timer, but you're not you're not gonna pay attention to the timer. I'm actually You'll ignore it. That's my job. Fine. A timer like Kevin. Yes. So, essentially, we had already mentioned briefly that the way this, works at a basic level is that data is replicated across all these individual servers and, you know, people's computers around the world, and those are called nodes. Right. And the question, of course, has to arise. What happens when there is a dispute amongst the nodes? What happens when node 1 and node 33 say, no, the data is actually node 1 says one way and node 33 says the other way? And before we even get to there, what is the data? So we talk about blockchains. Right? What is a blockchain? It's a chain of blocks. What is a block? Wow. Thanks. I I know. Right? Was that was that definitionally circular? What is a hand? It is something that displays the characteristics of a hand. What is a blockchain? It is a chain that has blocks in it. I know. I'm like it's we're mind blowingly like astute and wise in this in this episode. But essentially what is a block? A block is a defined discrete piece of data that contains different elements of of of things important to the chain. So it's going to contain a cryptographic hash of the transaction used oftentimes, using Merkle Tree cryptography. So a Merkle ized hash, whatever that means, that's gonna have the previous block, the hash of the previous block, meaning the previous defined set of data and its current data. So that's and then that becomes like a hash that again can get proven cryptographically between the nodes that this hash is valid. It's gonna have some metadata at the top of the block sort of on the version of the chain, you know, versioning, you know, like we're all familiar with semantic versioning, versioning of the chain, other kind of pieces of metadata, and some other bits and bobs is going to be in the block. And so that block gets then disseminated across the nodes for consensus, and that's where we get to consensus mechanism. And consensus has to happen fast, efficiently, and also has to happen securely. And that's a complicated, dilemma. How do you affect fast oh, and don't forget, obviously, it goes without saying decentralized. Right? So how do you affect a decentralized and crazily fast and secure consensus across nodes around the world? Right. Because you you need to ensure these things. So that's where the mechanisms come into place. And there's different consensus mechanisms, and they you can kind of imagine them on a spectrum of decentralization and and and centralization, right, to try and to try and grapple with these things. The the most famous one that often people are aware of is the Bitcoin model, which is proof of work, a proof of work consensus. Proof of work consensus basically requires the servers to solve very complex mathematical operations in order to validate the transaction and then create that new block. That is the least centralized. It is the most decentralized because it doesn't designate or delegate any any node. It's just whoever finishes the mathematical operation first gets to be the node that offers the validation proof that again again gets disseminated across all the other nodes Oh. For validation. But Sorry. And by doing it first and providing the validation proof, you get more of the insight. You get the reward. You get the reward. So you're trying to get the in that model, you're basically There you understand the incentivization model there. And you burn the planet in that way because it's really computationally expensive, but you get like, and that's that model. But that isn't that's not universal. Every No. No. No. That's not universal. And I I by the way, I think to understand a lot of this, one also needs to understand game theory and, the whole pursuit of game theory of, like, how do you incentivize players in a game to complete compete? Where do you find the equilibrium of players? Like, what in game theory, we call that the Nash equilibrium. Like, what is the perfect moment in a game where all players are playing their optimal moves, that's called the Nash equilibrium game theory. And there's a there's really interesting like economics and game theory and cryptography, like, a lot of stuff that goes into this, but that's not for here. Beyond the scope. Yeah. Yeah. That's for beyond the scope of this conversation. So that's called proof of work. The problem with proof of work is it's incredibly energy intensive, and it's destroying the world. Okay. So let's let's put that in a category. We don't wanna destroy the world. We kinda like this world. You know? It's got its problems, but it's a nice place to live. It's maybe our only place to live for the foreseeable future. We kinda wanna keep it going. I know Kevin, you got a couple kids. I have a couple kids who kinda want them to have a world to live on. It's a nice Yeah. Yeah. You know, it's fine. Maybe we wanted to go. Okay. Yeah. So then the the the other model that is very popular, is called proof of stake. And so as opposed to proof of stake, proof as opposed to proof of work, proof of stake is essentially that, the node operators stake their token to validate. And the ones that stake more, as collateral tend to get chosen more to be the validator, and then they get more stake and they get more back as a reward. There's a variation of this called delegated proof of stake where also delegators can participate in this consensus mechanism and can choose. So I'll tell you that people, other people who are playing in this game can choose a node operator and say, I'm going to stake as well on that node operator and I'm gonna get a portion of the reward and the operator will get a portion of the reward. And so people get to choose operators. So the benefit of this is it's less energy intensive by far, dramatically less energy intensive by scale, extraordinary scale. It is clearly a little less decentralized, because right? For obvious reasons. But the energy intensive nature of it, the the fact that it doesn't really destroy the planet any more than any other web application destroys the planet, is is a good thing. Like, let's say that's an unreserved good. It's a good. Right. And there's other models as well that are even less decentralized. There's something called proof of authority where basically the chain chooses, through its however the chain chooses things, and that's a whole another conversation. But the chain chooses approved approved nodes to be the validators. And those are unapproved like an approved list of node operators that can validate. That is clearly not super decentralized, but it is obviously also much more fast. And and you could argue more secure because you've you have a defined list of vetted As as long as those nodes are kept secure. But, sure, you're right. As long as nodes are kept secure. I'm kept. In this in this world of it, it has to be energy efficient, decentralized, secure, fast. It's like the all of these various models It's like a trifecta of a dilemma. Yes. Exactly. So so all of these all of these, you know, do it different ways, and I'm sure you build your applications on different And you also need to have an element of fault tolerance for bad actors as well. Sure. And we call that the Byzantine general's dilemma. And if you ever heard of the Byzantine general's lemma. It doesn't it's not from blockchain, but it applies to blockchain. It's the have you heard of this, Kevin? No. No. So very briefly because this is actually quite fascinating. Let's say you are that it comes from, army met army terminology. You are the Byzantine army, right, and you are surrounding a city and you're, you are proceeding to invade the city. The only way to tell all the generals that are surrounding this quite large metropolis that it's time to go, like lunchtime, is by sending messengers to all the generals around the place. And you don't get feedback from the messengers whether the generals have accepted or not. You just have to assume that all the generals will then activate their whatever they call them in armies, brigades. I don't know what whatever the thing is. So you have to assume that a certain percentage of your generals, either by malintent or by incompetence, will not activate their brigades. And maybe they're traitors. Maybe they're just bad at their jobs. We don't know. So you have to have an element of tolerance for ineptitude or for maliciousness. And all of these systems have to have what we call technically the BFT, the Byzantine Fault Tolerance. The twins' exhausting, but I get it. It's really really interesting. It's really interesting from, like, a nerd perspective. So so just to help me understand, because I really wanna jump into, like, if you could if we can maybe build a little dApp, decentralized app together if you're open to that. But do that. But but just to help me understand, just at the core, there are a few players here. There are the developers of a chain, but they they will inevitably participate in it. But those two things are not are not a given. Then you're in the participation of a chain. You have validators, and and they are they might be on an approved list. It might be whatever. You have to Depending on the mechanism the chain is. Depending on the mechanism, they will validate and and drive consensus on what the And send and send those validated blocks and they'll send those validated blocks to all the other nodes to That was my last question. And then nodes are generic whether you validate this or not, and then you have what I may just call users, standard nodes, not There are differentiated nodes, and, yeah, that's what you're, I think, intimating at right now. Yeah. But but but there is there's there's what we call user. There's what we call full nodes, which are the ones that can validate and affirm and do all the operations of a chain. Sure. Then there's archival nodes, which as the name sounds, are there to preserve the history of the chain. And then there's things that we call light nodes or light clients, which participate in some of the operations of the chain but don't validate. And those are really helpful when you have low low infrastructure, like if you wanna have a mobile app participate or you wanna have a wallet a mobile wallet participate. It would just be like users. I'm a consumer. Basically users, and they would query full nodes for more data, but they themselves don't possess the entire history of the chain, and they don't participate in the full validation of a chain. And there's other nodes as well, but those are some of the big ones. That's really interesting. And then just my final question, just to make sure I got it. When I I'm a user. I have a I run a light node, which could be a client, right, a web app, whatever, and I want to gain data. I'm not going to a specific node for that data. No. I'm asking the the chain. There is a mechanism for me to just go out and say, I would like the latest version of a thing. No. Because all the nodes should have the latest version. So there's different ways there's different ways of doing that from the, application Velma perspective as well. Some chains can expose things like GraphQL API endpoints that allow you to query the chain through like a GraphQL API query. So from the web app developer, it doesn't feel any different than you're building any other app and you have to unfortunately use GraphQL and create very long verbose queries that you could just do with the REST API. But that's for another episode of yours. But so, so it doesn't feel any different from that perspective of a web developer. And then you would there's also the the archive nodes that could be used just to query for data. And so you're querying specifically to the archive node asking it for, you know, current state. That's another example, but often it's through, like, API endpoints that are exposed. But then if I want to participate, that's the difference between a read only application and one that I can post a status to or something like that. And at that point, I'm no longer a light node. No. I I could be a light node. Light node. Even when you're sending a transaction, you can still be a light node. It's not gonna be validating it right now. You won't be validating and, and unauthoring and participating in the authoring of that block. You'll be spending the transition transaction to the chain to be included in the next block, I. E. The next discrete data bit, but you won't be part of the affirmation process of that block. So we have to summarize, and I know this is still a a a light version and a bridged version of reality. We have light nodes, which you can think of as just users of an application. They can query. They can send data in. Then you have, then you have full nodes, which are part of the they are they are basically the keepers of the chain. They will, based on some mechanism, decide what is what is true amongst themselves with some degree of fault tolerance call, and they generally will stake some kind of resource on their ability to do that accurately fast accurately and and correctly. And then you have archival nodes, which just store state, but they won't be part of that consensus mechanism. And there are various other kinds. These are these kind of big you I don't think primitives is the right way, but categories of these nodes. That makes lots of sense. I would love to see this in action, and I'm sure I will have loads more questions. I love that we had this conversation, by the way, Kevin, just to reflect on it for a moment. I think what you're doing is so valuable because we all come to things with a lot of opinions, but to be able to gain just and most of us who are listening to this or watching this later, not all of us, but a lot of but many of us will come at it from some set of technical background and we approach things from a technical perspective. And so to be empowered more with the technical implementation details, it's not that it's to change one's opinion either which way, but to empower one in their opinion, to give them actually and maybe it does change your opinion. But, you know, we approach things through technicalities and through understanding technical specs. And so this conversation doesn't happen enough. So, really, I think it's a really, really good thing that we're doing this. Thank you. And that's really the point of this series is I'm trying to put away the, you know, any negative, bias that I come with, and you're one of the people I trust most to come in and kinda just cut the idealistic vision piece, which a lot of folks because I'm such a I'm such a pessimist realist. Such a pessimist, but but I I knew I know that I can just pause you and go hang on. We're going on an idealistic train here. I and we haven't Good faith. Too much here, but, like, I just wanna know. I just have questions. Now I've already learned stuff. There was also some assumptions I had. I don't wanna kind of ruin where where I land with this, but, like, not every blockchain has to be tokenized. That is really interesting to me. So there is a technical nature of this where if characteristics are are correct for your use case, You can use this, and it doesn't have to be backed by by cryptocurrencies, which many see as scammy. And I will not pass comment on that in this moment. But those 2 those 2 worlds, they are not they are quite linked, but they are not inextricably linked. Like, they can exist. One one could say I have evidence. I think this is an actually an accurate thing to say that cryptocurrencies are an articulation of a use case of blockchain, but in itself is not the totality of blockchain. It is by far one of the most and maybe the most prominent use case that's been developed to blockchain. And for obvious reasons, human nature, right? We as people tend to want to seek things that will improve our wealth standing and improve our, That's just how we are. And if we're being honest with ourselves as people, that is that is like baked in to to humanity. So that's it. It's not a surprise that new technologies often get articulated early on by those seeking profit first and foremost and maximizing profit. That is true with all new technologies that have ever been developed, including decentralized ledgers like blockchain. But that isn't but I think what you've said in the reality are not the same thing there. Like, if crypto I I would love to get into the demo in a moment, but just to kind of, articulate my response to that, like, sure. I've heard loads of people in web 3 say cryptocurrency is but one use case. It is but one very common use case for it. However, it's until this conversation, I believed every other use case was built on top of that on top of cryptocurrency. Therefore, they are 1 in the same. It's not a use case that it is the fundamental piece that without this whole thing doesn't work. Well, that isn't the case. You just have to flesh out the distinction between tokenization of incentive and cryptocurrency. Those are not exactly the same thing. That an internal system has a way to incentivize participation and using your resources and time and hardware is not the exact same thing as cryptocurrencies as a competitor to, you know, a government backed fiat currency. Right? Those are those are 2 interweaved, interwoven, whatever the correct grammar is there, but they but they're they are slightly different. Yeah. Cool. Good to know. And then the other thing was just I think I just didn't understand enough about the tech, the characteristics. I'm starting to get that a little bit now. If you're able to, if you're willing to Can we look at something together? I would I would love that. I would love that. Let me just see if, let's do this. So I did ask you before this to maybe, like, prepare a little something. So I'd kinda be curious just to set the groundwork for for what we're gonna do. I'd love to know what we're gonna look at together and maybe just the background of, you know, there is gonna be some level of infrastructure already in place. We're not gonna go and set up, maybe we will, but we you know, this may be be built on top of some existing chain infrastruct the the wording, I'm not quite finding No. I appreciate that because I think that'd be given the time constraints, we're not gonna build together on this on this, moment at this moment. But what we will do is walk through some of the code because just like what we did, now by demystifying some of the terminology of the technical specs and how it works from a technical layer, I think it's also equally important, and I think you agree on this, to also demystify some of the technical specs. And when we talk about decentralized applications or dApps, how is that actually different from any other kind of app that one may build? And, you know, the TLDR, by the way, is just not that different. It's quite similar. And, and honestly, from a design perspective, that was intentional because if we want to help people build, developers to build in a new space, do you create an entirely new way of doing things, or do you just build on top of the familiar patterns anyone has when they're building, let's just say a web app or a mobile app, right? So you're gonna do the exact same things and in many cases use either the exact same language stack or slightly modified domain specific versions of that language stack, And and, and this case is what we're gonna look at, and the latter is what we're gonna look at. So what we're gonna look at is very briefly a very small sample dApp, to essentially create your own personal micro journal or microblog that you can store your thoughts and only you can access your thoughts, and it's it's your kind of, like, personal remember they used to be these web apps. I forgot what they were called even. Maybe LiveJournal was one of them where you could publish your thoughts and remember that. Was it LiveJournal? It was LiveJournal. Right? Yeah. It was. And was LiveJournal gated, I. E, like, I can only see my own thoughts if I wanted to. Was that a setting? I think you could share it or you could you could make the setting that you don't. Right. Yeah. So kind of a similar idea, a scaled down version of that. And so if we look in the folder structure, what we see is actually 2 different folders. We see what's called here a blog contract as one folder and then the front end as the other folder. And, that's obvious that in our case of a dApp, the back end is called the contract. The back end is a smart contract, and I think it's not an exact one for one synonymous comparison, but it is a great simplification of it for our purposes that a smart contract is essentially a piece of executable code that lives on the chain, that lives on the blockchain, lives on a block that can be called to do things. So it's code that lives on chain. And the 1st blockchain to make programmable blockchain possible with smart contracts is Ethereum. Right? Before Ethereum was Bitcoin, Bitcoin was not a programmable blockchain. You cannot put smart contracts on it, but Ethereum was the first one to make that possible. You put code in a block. It goes in the chain. All the validator nodes go, yeah. Cool. This is part of the chain now. And at any point, I can call the code that lives on the chain. Yeah. So, actually, let me show you very briefly. Let me open up a code editor here. So if I No. I don't want to bump up that font size. No. But this is I will bump it up. I know. I just opened it. But, let's see. Where is it? Why is it not I'm not seeing it. Oh, it's in here maybe. Wait. Where am I missing it? My dot env. I don't know why I can't find it right now. Should be in there. Anyhoo. So Maybe it's oh, I know where it is. Sorry. See, this is real time. Right? There it is. So in the front end side, so in fact, the only thing I have in my dot end file is my contract ID. And what is my contract? I'm using a React. My front end revealed. It's a React app on the front end. Oh my god. The great reveal has been shared. But, what is and, you know, you preface, you know, your dot end variables in React with React app to make them available. Right? That's kind of the part of the architecture of React. So what's the contract ID? That is the address of my code on the chain. That's the that's the, the place, the location identifier of my code on the chain, Which you don't need to do on the chain. That's not private. Right? So I'm just using dotendvariables just for convenience, but this is my contract address for this contract. Right? So this is the the location on on this particular chain, whatever chain I'm putting in. This is similar this is similar to, like, writing some code that has to be hosted on AWS. You have to deploy it to get the URL in order to call a serverless serverless serverless serverless serverless serverless serverless serverless serverless. This is the equivalent of the URL. Exactly. And anyone could query this chain and see the contracts that are on this chain, anyone. And and look at this address and see the code that I've uploaded at this address through a query for a a block explorer. Which is how you increase trust because anyone can Exactly. That's fine. It's how you eliminate the need to have trust. So, I mean, I think this is that might be idealistic semantics, but it's how you build trust. It's I can go look at it. Right? It's how you label people to verify for themselves, basically. Right? Sure. So, okay, so we have these 2 folders. We're going to close the front end just for a minute just so we could walk through the back end, the contract, because I think that's a bit more interesting. So just by full disclosure, what you're going to see is one implementation of smart contract architecture. This is coming from the company I work at because why not? I work at Fuel. It's building an execution layer for Ethereum. So when I talk about an execution layer, I'm talking about and I'm gonna give you a 60 second synopsis of this because if I don't, it doesn't make any sense. When we talk about execution layer, we're talking about in the context of a modular architecture where you separated out the concerns like a separation of concerns, kind of like a models, views, controllers, MVC model, web framework, where you have the consensus layer and the execution layer as and there's another layer as well. I can't remember on top of my head, but someone will tell me in the comments, I'm sure, once this is out, and I'll look it up as soon as we're done, but the you separate out those concerns and there are different, parts of the different parts of the chain functioning in different ways and sharing the data between them to enable, basically higher throughput, right, higher speed. You you you have dedicated parts of the chain that do dedicated things in order to just, well, it's it's good. It's good architectural design, first of all, if you believe in like microservices, and it's also it just makes it more easier to debug when there's problems, and it increases increases throughput. Right? Some of the benefits. So we're building out an execution layer. Right? So as part of that developer centered kind of experience, we built out a DSL, a domain specific language for smart contracts called Sway. It's based on Rust, so it's it's Rust based DSL. So it looks a lot like Rust, but incorporates a lot of features that make it a lot more intuitive for smart contract design or more tailored to smart contract design. And so in that context, everything starts at a main file. And the main file, you can have 3 types of files, contract, which is the executable state full piece of code on the chain. You can also have a script, which is, can access state but is not stateful. Right. It's only state oh, actually, I take that back. It's stateful in the moment of when it's executed, but it doesn't hold state. It doesn't keep state. Like a serverless function? Sure. It's like a it is a serverless function. That's exactly what it is. Amazing. And the other, the other type of thing you could define here is a predicate, and predicates evaluate to true or false. They they don't hold state and they don't access state. They evaluate a a, a, they basically create a a Boolean evaluation. And if the thing evaluates a true or false, that can then call a transaction on a chain or it can call a thing to do something on the contract. So you could incorporate that kind of interface. You can incorporate that kind of functionality, I should say, in a smart contract. But to further round the separation of concerns, removing out that true or false, like, did I give you 50 tokens or not? If I gave you 50 tokens, do this. If I didn't, don't do that. So instead of having that as part of a contract interface, I take that out and I just make that its own little snippet of code that just checks whether this is true or it's false. And then if it's false, do y. If it's true, do x, and that's essentially it. So that's the 3rd type, of of code you can have, contract script or predicate. Can I ask one quick question quickly? Of course. So we've got 2 parts. We've got front end, which will just run-in a browser that can be hosted on AWS or Netlify or Or Vercel or Netlify. And we have the back end. I understand it's not a a straight one for 1, but the executable code that will touch state and the rest of the chain, the database in the it's not quite that, but whatever. And that is that lives on the chain. I'm one thing I'm not really getting is when does the user of the React app, like, have to provide token to participate? Like, what part what part of this does this touch a a store of token? They may or may not ever need to touch token. It just will depend on the design and the decisions of the particular application developer and what they want to build. So if they wanna build something that requires the user to pay for things or then they would need to provide some token. If you don't want to build something like this small sample application, which I'll run-in a moment, you can see it, it doesn't require any any token because there's nothing it requires an account. It requires a wallet address because that wallet address becomes your identity, but it doesn't require any token. If you want to build something that is you know, a marketplace, I think you would probably wanna have token. If you don't wanna build a marketplace, you don't you're not building a trading platform or a lending platform or any of those kind of things, then you don't you don't need to have token. If you want to pay for the cost of querying the chain because, you know, that has cost to it because you're using people's infrastructure, then you as the application developer can cover that cost. And maybe you have other revenue models for your application. Maybe it's through advertising. Maybe it's through, all the other ways app developers in any in any web space get revenue. Right? Like, it doesn't have to be through the user. I think you answered it. I might just dig what a little more you said. If the application owner wants to pay for the I forgot the exact wording you said. I'm a little bit confused. This is being hosted on a block on an Ethereum blockchain. It's being hosted on a fuel on the fuel testnet. Right. And that is We're not yet to, like, production main status on deployment of this block, the submitting this this executable this smart contract, that would cost some money. And then to query it would cost some So when I right. So when I would publish a new journal entry, that's putting data into the next block that will be finalized, which costs money, infrastructure. It's infrastructure costs infrastructure cost. That is equivalent of AWS cost or the equivalent of AWS I'm not I'm not against it. I'm not trying to be like, oh, you have have to pay for it. I'm for pay people for for infrastructure. I was just trying to understand what, where, how And so you as an application developer can choose how you, you know, build your cost models and your revenue. Wallet addresses their ID, so that is kinda how this all hooks into it's like log in with PayPal. You know? Yes. So exactly. So There's a wallet there with money in it. In the other in the more, you know, in the prevalent kind of web 2 models, login is done with login and password or login with username password or login with social accounts. In the web 3 model, login is done with your account, your wallet account, your ID. And that's an immutable address that links you across, you know, the network, and, and you can use it in any way you want. Many people have many different wallet accounts for different things. Right? So I may have a wallet account that I keep in a place that's very hard to access online and I where I may keep more of my funds. I may have a wallet account I use for debugging and, like, testing things when I'm building applications and many of those. I may have one I use for, like, common, you know, web apps where I'm using, you know, the very popular Chrome extension called MetaMask or a browser extension to enter, and I don't want to, like, put a lot of sensitive data with it. So I may just use that for, like, you know, social apps where it's requiring me to log on. And there's all different sorts of addresses you use, but the address becomes your login. Got it. So they're inextricably linked in this setup. Again, these tokenless tokenless blockchains are completely separate from this. It's a different implementation of the same concept. So I'm sorry for interrupting you. I just felt that was really important. No. It's an important thing. And so should run us through. Yeah. Yeah. So just to very very briefly run through. So this is essentially a lot of Rust syntax, so it looks a bit like Rust, but if, but with any Rust developer would see differences. But here I'm including some modules and because I separate out the concerns, I have a module I created for my data structure. I have a module I created for my interface, meaning, you know, so I have down here an implementation block and this sounds familiar to a lot of different languages as well. So I have an interface that defines what my code will look like and what each thing returns. And then I have an impl block for the actual implementation of that interface. Right? So if I go to the interface and it's in a file called interface, look at that. If I go to my interface, I see this is a library. Right? This is not a contract. It's the library. And I'm using my data structure of a post, which we can look at in just a second, and I'm also using from the standard, Rust library, vector, storage vector, a data type, right, kind of like an array, and here is my interface, my where I define what a blog is, what is inside a blog. It has a post function. It has a get post by author function, initialize user function, a get number of posts function, and a get post, and each one of them returns a different thing. This returns a vector of posts. This returns an identity of a user, which is a type. Right? That's a class. This returns a unsigned 64 bit integer of getting number of posts and this returns a post. When I get a post, it returns a post. What is a post? A post is this. And where I define posts? In the post file. I love it's simple. From okay. You know, my background, by the way, Kevin, is I was a for a long time a Ruby on Rails developer. And we have to get back to that, right? Because one of the things I love about Ruby on Rails is the convention over configuration and that things live in certain defined places. And one of the things I find most frustrating for myself personally, just speaking personally, in the JavaScript framework landscape is the lack of convention. And I love frameworks like Vue, for example, that start imposing a bit of convention. And so I can go into a Vue a lot of Vue web apps and I start understanding you introduced me to Vue, and I'm grateful for you to you for that because I can go into Vue and I can at most web apps and get a sense of the land fairly quickly. With rails, that happens instantaneously because of conventional reconfiguration. So this kind of convention makes me very happy. So I go into the post data structure, and this is another library. Right? And I have my struct, which is kind of like, a class in Rust. I have my struct for a post, which has 3 types, 3 fields, an ID, an unsigned, 64 integer, a content type, which equals a string of 280 characters, and an author, which is an identity. And then I have an implementation of my post where I can create a new post. This is like a class method. Right? Create a new post. And it returns back the self containing an object of ID, the content, and the author. So that's now getting back to main. So I have I've included these two things in my main, which is the main interface for the applications, the call point. It's like the app dot JS or what have you. And then I'm saying I want to use all these different libraries. I want to use a hash. I want to use a vector, etc. I want to use my post data structure. I want to use my blog interface that I define. And then I have a storage. This is what it will be go into my block. This is what gets published in the block. What gets published in the block are the posts, the number of posts, and the user. And so the post is a map of key value, the key being a number and the post. The number of posts is just a number, and the user is an as an identity. And using option, which is, you know, oh, helpful, helpful, Type that represents an optional value. Right? It's an at an enum that represents an optional value, either some or none. So I default it to none, and then I provide it with it. And then basically the rest of it is kind of standard Rust code. So, this is meta programming in Rust. This actually goes if you would dive into the Sway code base, you'll find, like, hundreds of lines of code defining what this is. But this is Rust uses a lot of meta programming or you can use a lot of meta programming in Rust to define macros. So these macros, like, abstract away a lot of the things, so I just have to write my actual logic. And then this is, like, create a post. This is get a post, and this is initialize a user and etcetera. And then that's basically the back end. Does that feel dramatically different? Obviously, it's not JavaScript or TypeScript. It's Rust, but does it feel dramatically different to you? No. Not particularly. I'd be interested in the intricacy where it starts to involve token, but, like, no. Not on the surface. And this these are, as you say, the primitives. Can we see the front end briefly? We're we're starting to we're starting to run on both of our times. Very, very briefly. So the front end, essentially Even just the API calls would be interesting. Yeah. So let's go to, the so first of all, it's TypeScript. It's a React app with TypeScript, and we then generated a lot of different type generate a lot of types for the front end to interact with the back end. Right? And so if we look at the front end, well, that's the index file. That's not so interesting. But if we look if we look here, we're using we're basically using the the, we have a, a wallet SDK for TypeScript, and React libraries within it, and that allows us to basically, you know, abstract away a lot of that concern as well. So we're importing useAccount, use connect, use wallet, use is connected. These are different, like, what's the fancy word for it in React? But different, like, state, verifiers. Right? So, like, if I go sounds plausible. That is but it's not it's not the term in React. We know that. But I'm not a React developer. I barely can write React, essentially. Neither am I. You told me I taught you Vue, and then immediately, here's the React app. I know. What can I say? I what can you do? So, you know, we're basically defining the different state of the app. Right? So, is connected, uses that, connect, yada yada yada yada. And then we create posts. We use state. We create a post as an empty array. New post content is a string, etcetera. We define a type for post output, with different, you know, parameters and their types, and a type for a post, and then we set the wallet address. So once we set the wallet address, if I was building an application with tokenization as part of it, then I could also do things like request payment. I could request to pay. I could send token, and I could do all that sort of stuff. I'm I'm not doing any of that here. I'm just getting the wallet address for the contract from the person. And then the rest of it will kind of look similar to another any other React app. I define some some functions like get posts, and then, you know, like, the checks, like, if there's a value, if there's not a value, right, I wanna catch that and put a console in the log. Like, it's not that's kind of standard JavaScript React programming or TypeScript in this case. And then down here is the actual front end Sure. Kind of standard. So if we run this, so let me go into the front end. Now if I can type. Thank you. It's fair. It's what I write most times. I so appreciate that. Set up an alias. I should alias it as well because it's even in there. Look at that. Nom, was there for a second. Alright. So npm start, and it's gonna pop up. Look it doesn't look that different if you were just using any kind of authentication service plus a payment service, I guess. So this is, like, my this is my my little blog. Right? Like, this is exactly what it looks like, and there's no post in there currently, but I could write a post. Let's see if this works. It may not work, but let's see because I haven't played with it in a while. But we're live. This is fun. This is a post of mine. And, of course, it's not working right now. Because that's the that's the law. That's the law of things. We don't need to work it out. In theory, that then gets submitted as a block on the chain. In theory, it gets submitted as a block on the chain. I do not know why it did not work, but it did not work. Oh, there we go. Thank you. Now it's working. I don't know why it didn't work before. I think I was making changes. I didn't save it, the file. That was the that was very basic. So here you see it prompted already because I have 2 wallet extensions loaded. So it's asked me which wallet I want to connect with. Right? So initially, I've these are just 2 different wallets in our ecosystem, and I play with both of them. So I'm going to connect with this wallet. Why isn't it Is it the fact that you're in this little mini arc thing? Oh, no. Popped up another one. So I'm connecting. Right? And it's saying, okay. You wanna connect to this application on local host. It wants it can view your balance and activity and then and can request approval for transaction. Like an OAuth flow. Yeah. Right. So I'm gonna connect. I'm sure that isn't the mechanism of that. That's Oh, why is it not working, Kevin? Nothing ever works when you want it to work in real time. Oh, now it's working. Yay. It's all good. It's all good. I mean, a lot of this is about illustration rather than, like, oh, I click So here you see my post, and let's see if I create a new post. This is a new post. Beautiful. Okay. Approve. Approve transaction because that's what's happening here. You're providing token even if it's is a text And there it is. This is a new post. And there it is. Interesting. Yeah. I mean, that's the case on the front end. It doesn't feel terribly different to This is why, by the way, I tell all my DevRel colleagues to always record their live coding for presentations and not do live coding from the state. Not. I think the wealth of knowledge that I have gained as a result of talking to you today transcends the fact that you pressed the button and and something didn't change. And by the way, the way this would start is actually quite easy. So, you know, you have, create react app, right, in the react land. If I wanna create a new contract, so we have a tool called fork, which is the fuel orchestrator, and I would just do fork new and the name of the contract and instantiate an entirely new contract for me. So fork new blog contract. Which which, just to be clear, is the local code required to write it. That would still need deploying. That would still need submitting Right. So let's let's get out of this for a second and see what that looks like. So fork new sample contract. And then if I go to sample contract and I take a look at it, it's very small. There's nothing in there. So so It just here's my AB. And you see it's not even separated out. So that can be that can be deployed. That could be That could be deployed. It's just a contract that returns a boolean of true, and it'll always be true. Right? There's not there's no operation happening. It's always gonna be true. It's really interesting. So that's I suppose I suppose a lot of the complexity here is abstracted away by helper libraries It provided by fuel my guests, which is really interesting, all the ecosystem writ large. But, thank you. That was that was a great episode of learning things I love to hate. I hope that that was that was good for you. I feel like I hopefully didn't ask too many really difficult questions, but the questions I did ask allowed Kevin, anyone who knows you knows you are a wonderful person, and anything you ask is fantastic. I think this is a very good conversation. Thank you for inviting me. Thank you for being part of it, and thank you everyone for watching this. Until next time. This has been learning things I love to hate. Bye for now.","published",[146,156],{"people_id":147},{"id":148,"first_name":149,"last_name":150,"avatar":151,"bio":152,"links":153},"82b3f7e5-637b-4890-93b2-378b497d5dc6","Kevin","Lewis","a662f91b-1ee9-4277-8c9d-3ac1878e44ad","Director of Developer Experience at Directus",[154],{"url":138,"service":155},"website",{"people_id":157},{"id":158,"first_name":159,"last_name":160,"avatar":161,"bio":162,"links":163},"5ea15ec0-b2fc-4458-96bc-cb509c9e9105","Ben","Greenberg","a87b871d-adec-4f7f-bcb4-9b5c1ad105b5","Head of Developer Relations at Fuel Labs",[164,166],{"url":135,"service":165},"twitter",{"service":167,"url":168},"linkedin","https://www.linkedin.com/in/hummusonrails/",[],{"id":171,"number":139,"year":172,"episodes":173,"show":177},"bf1ea922-80fc-420e-ac6a-fa17d6a2ab3e","2023",[122,174,175,176],"120171fc-b80d-4940-ba66-a16ea67a1aba","91cbc0a4-a6a6-462f-8f80-768ab96db9d1","4c5904eb-cc3b-4c54-b0a2-701be5ada53d",{"title":178,"tile":179},"Learning Things I Love To Hate","4a962a76-2351-477b-be15-c3f1fca6f82b",{"id":174,"slug":181,"season":171,"vimeo_id":182,"description":183,"tile":184,"length":185,"resources":186,"people":190,"episode_number":195,"published":196,"title":197,"video_transcript_html":198,"video_transcript_text":199,"content":8,"seo":8,"status":144,"episode_people":200,"recommendations":203},"edge-computing","893709475","Kevin is joined by Pandelis to properly understand edge computing, and how they evolve from CDNs and distributed compute.","725ad1de-038d-4832-8344-e5d782c10974",60,[187],{"name":188,"url":189},"Pandelis' Twitter Thread","https://twitter.com/PandelisZ/status/1726957806820164032",[191,194],{"name":192,"url":193},"Pandelis Zembashis","https://twitter.com/PandelisZ",{"name":137,"url":138},2,"2024-01-02","Edge Computing with Pandelis","\u003Cp>Speaker 0: Hello, and welcome to learning things I love to hate. This is a show where I basically stop putting off learning things that I have avoided for one reason or another, inviting in my friends and experts around the topics that I'm trying to learn. And today's topic is edge computing, a topic which has got a little spicy in web circles in the last few weeks. I'm inviting my lovely dear friend, Pandellus, here today. Pandellus, would you like to introduce yourself?\u003C/p>\u003Cp>Speaker 1: Yeah. Hi, Kevin. Nice to see you again. Yeah. I'm I'm Pandellus.\u003C/p>\u003Cp>I've been an engineer for the last few years working in web, working in in deploying a lot of the things that I claim to write. I've worked in web agencies where delivering content to users was super, super important. Back in the jQuery CDN days where when edge computing was basically only CDNs into kind of our modern edge computing world now where we can put entire runtimes, entire databases onto the edge. There's all things I've experimented with at various companies. So I I'm so happy when I saw your tweet.\u003C/p>\u003Cp>It's something I've been experimenting with a lot. And, as someone as a user of the web, I think it's something super important for for everyone to to to to to know about and experiment with.\u003C/p>\u003Cp>Speaker 0: Awesome. And, and yeah. So I tweeted out a few days before this recording. Can anyone just, like, explain edge computing to me? Because I really don't understand it.\u003C/p>\u003Cp>And you came in with a wonderful set of illustrations, which actually will just edit in here right now. These are the illustrations, to kind of explain a little bit about how Edge works. So I thought, hey, I'm just gonna invite you onto this show. This was already a topic I was planning on talking about. You preluded, I suppose, some of the things I wanted to discuss today.\u003C/p>\u003Cp>So just to just to open with this, I wanted to explain kind of where my knowledge is now, and hope that you might be able to take me and anyone watching who's in a similar spot through that journey of understanding more. And perhaps if we have some time at the end, we can do a little demo of this abstract concept. So what I know of edge computing, I think, really is around content delivery network, CDNs. We can maybe start a little bit about talking about this. And I know that the concept of what can be stored, you know, and replicated in multiple regions and serve to people based on where they are in the world has just grown more complex.\u003C/p>\u003Cp>We we're doing that with more things. And I suppose my biggest concern and the reason I haven't really done it yet is, 1, the idea that, you somehow need to replicate things really rapidly in lots of regions. And 2, unrelated, it just seems really complex, and I'm not sure how how much the complexity is worth, what might be a payoff that doesn't matter. I know there are some performance hardcore people who are like, of course, it matters. But, yeah, that's kind of my starting point.\u003C/p>\u003Cp>So maybe if you take us back, talk a little bit about CDNs and what they are and kinda how that's evolved to where we are now, that would be really good.\u003C/p>\u003Cp>Speaker 1: Yeah. Of course. Yeah. No. I mean, as engineers, we like to make our lives harder for sure.\u003C/p>\u003Cp>It's it's it's we we we do sometimes like to like to overengineer, and it and it's all as with everything in engineering, there's a million ways to do them. Not all of them are right, and a lot of them are right. So your mileage may vary with your needs of edge whatever. A lot of people don't even need the CDN, but it comes down to your users. Right?\u003C/p>\u003Cp>It always comes down to your users and the experience that you're trying to deliver. So let's let's start with CDNs, and what is the problem that that that CDNs solve? So if we go back to the mid 2000, when jQuery and, you know, serving libraries over the wire were were were all their age, we would, you know, blindly go to, CDN stack or whatever those CDN websites were and grab URLs for for jQuery and put them in our sites. Before build systems, before your web packs, before the the the modern JavaScript ecosystem back in days, CDNs were all their age because we wanted to deliver large JavaScript bundles to the user quickly. Internet was slower, and still is slow.\u003C/p>\u003Cp>Or this is h t p one days, right, before streaming h before multi, you know, multiple h t p two streams, and all that type of stuff. So it was very important or we people saw a lot of gain in having these large JavaScript bundles close to the user, meaning the end users could consume that JavaScript faster. And in the end, what that means is when they get their HTML through, it becomes interactive faster.\u003C/p>\u003Cp>Speaker 0: Could I ask you a question? Could I pause it? So when you're saying near to where people are, just to clarify, we mean that this one jQuery bundle or whatever is stored on multiple servers throughout the world. I request it via one URL, and then the application which will serve up that file will find the place nearest to where I'm making the request and serve it. And then the additional benefit of CDNs, I suppose, is if I visit 10 sites that all are trying to load the same large bundle, this might be more CDN specific, and I think it also might be a relic of the past, but it\u003C/p>\u003Cp>Speaker 1: it would not It is a relic of the past. That's that's that's one of the topics I was gonna touch on. In in the early days, it was when there was less CDNs around, we we could make the ex we could make the excuse that, okay, by using a shared CDN or, say, a common example was also Google Fonts. Mhmm. By using Google Fonts, by using a common CDN, it means that there's a higher likelihood that a user would already have those assets on their computer.\u003C/p>\u003Cp>Cached.\u003C/p>\u003Cp>Speaker 0: Okay.\u003C/p>\u003Cp>Speaker 1: Exactly. So it's a further cache. Ultimately, the the most edge location is the user's computer. So caching is always a tiering system and CDNs are a type of cache, and the ultimate caching is local. When you have a local cache, that's that's the ultimate edge.\u003C/p>\u003Cp>And really with edge compute, with edge with with the topic of delivering on the edge, what we're trying to achieve is native like performance, and the most edge you can get is being on device. So, arguably, the the most edge computing delivery method today is an app. Apps are on your device, and there's no more edge than the the the device that you're touching. And everything that we're doing on the web or or in edge compute land is to try and achieve native like performance.\u003C/p>\u003Cp>Speaker 0: Cool. That makes sense.\u003C/p>\u003Cp>Speaker 1: So, yeah, those are those are sort of CDNs, and that is kind of the the most basic form of putting things on on the edge that we had. So that and that was, and there was a legitimate benefit to to to to CDNs. And what we've tried to do in or what has happened in in the modern era is CDNs themselves have become more and more capable, to the point where they can actually run and execute code. 2 of the most popular and, CDNs around are are CloudFront from AWS and, Cloudflare. And Cloudflare are one of the pioneers of of edge computing as well, and their CDN offering just over time naturally has become more has gained features, has had feature creep, and eventually, we wanted to do more complicated things over time.\u003C/p>\u003Cp>Right? We we may wanna deliver a slightly different version of a bundle for certain users. Or if it gets hit with a with a certain URL parameter, we might wanna bust the cache or or run some sort of, run something on that server that's delivering it, maybe do an AB type test, where certain users got certain bundles or whatnot. So at\u003C/p>\u003Cp>Speaker 0: some point transformations as well?\u003C/p>\u003Cp>Speaker 1: File transformations became yep. Image image CDNs. So moving from kind of just JS bundles, image CDNs are, again, super popular because, on super useful because, the the 2 largest assets that get delivered are the bundle and the images. And images also very bandwidth intensive and benefit largely from being closer to the user. Sure.\u003C/p>\u003Cp>And we're gonna we're gonna say closer to the user a lot throughout this conversation. And what that what that practically means is that you are spending less time in flight over cables. Your server could be very far away. And the further away it is, the longer it will take to navigate, you know, the the, the the sea of cables that live under the sea, to get to your user. So the closer you can be, the less hops we can make, the the the the the better for for the end user, but also for our bank, CDNs, specifically, not necessarily edge compute, but CDNs, specifically, also benefit benefit us in that we send less data out because it's also a caching mechanism.\u003C/p>\u003Cp>Edge compute, not so much when we when we get when we get down to it, because one of those goals is to have as fresh content as possible. So when you're when you're when you're caching, you're limited by the freshness that you can deliver. So that that's that's sort of that that's sort of the niche that CDNs sold for a while. And, yeah, more and more doing more and more things on the edge or closer to the user or doing more compute at the CDN level means that we could do these kind of transformation things that you just mentioned with images. Right?\u003C/p>\u003Cp>So say I wanted an image 30% smaller, we could deliver 1 all the way back from our original server, or we could use the kind of already existing cached asset and do some computation on it and then also cache that. And that's this kind of level of level of tiering that that that being closer to the user kind of offers us is is we don't wanna keep hitting our main server, and wanna keep delivering faster things to the user because, yeah, it's all about speed at the end with with with the goal of edge.\u003C/p>\u003Cp>Speaker 0: Cool. So now we're in a space where it's not just about storing assets, whether that's bundles, images, you know, media, whatever. It's actually about running computational tasks at the edge. So I suppose, naturally, that moves us on to maybe what what is edge compute edge computing? What is it capable of now?\u003C/p>\u003Cp>And then I suppose we're going back to my initial concerns or skepticisms. 1, how do you keep all of these nodes? I don't know if they're called nodes. I'm assuming they're called nodes in in sync, especially when you gave an example of, you know, doing transformations at the edge and then caching that. Well, is the cache just at a node level?\u003C/p>\u003Cp>Do they propagate throughout a network? Stuff like this, I'm not too sure about. And then it sounds really complex. How how does this actually shake out to being something that's tolerable to developers?\u003C/p>\u003Cp>Speaker 1: Yeah. Edge and the and this this edge cache or caching cash busting, in CDN land, it has always been a pain, especially in the days where I was working as at a web agency. So, basically, all all all that we deliver over the wire is is assets and and JavaScript and images, and it was definitely always always a battle of, okay, well, what is actually being delivered to the user and cache busting it and and and figuring out, oh, okay. Oh, they're on an older version of the of the site, and they're seeing old content and it and us getting rang up by our clients being like, the other site that we just published it. It's not gone live, and that's having to explain.\u003C/p>\u003Cp>Okay. You're gonna wait for the cache to propagate. It's it's gonna it's gonna get to the your user eventually. No. But we've we've launched this because, some context here.\u003C/p>\u003Cp>I used to work in, theater websites, where we had very peak peaky demand spiky demand and very, and certain requirements around, you know, if a certain show went live, they want it live now so that people can book it now.\u003C/p>\u003Cp>Speaker 0: Which is not an unreasonable expectation if I hit publish that I mean, that's even the thing with, like, static website building. There's always a build period, and some people don't get that that build period, you know, is can be quite material.\u003C/p>\u003Cp>Speaker 1: Yep. And that is also that's a huge challenge now with edge compute as well, but and also at the time with CDNs as well because we are we're still trying to we're managing demand, and we're managing speed. And the most fast asset we can deliver to someone is something that's cashed. So there's always a challenge on how you distribute or revalidate that cash. So in the CDA, it's so it's definitely I'm not gonna say it's anything that that's that's easy or perfect.\u003C/p>\u003Cp>It's a challenge at every level no matter how simple, even at the simplicity of image and and bundle cache, but also to the level of, of full HTML page cache. Right? So during during go during, say, ticket sale go lives or or certain events, we may sort of cache entire web pages, and that becomes incredibly complicated to deliver to many, many users because we then have the challenge of say, okay. What happens when the tickets now run out? And everyone should be seeing a, you know, sold out banner.\u003C/p>\u003Cp>And, depending on where you last were when that cache hit that node Yeah. And the the the way the way cash is generally work is, you know, it's a pass through cache, meaning, the CDN is the thing that will ask your server, make the request to your server for content, receive it, stream it back to the user, and also save a version on on that server. So depending on who access it at what time, there will be a cache with a certain time to live of 5, 15 minutes a minute. So meaning someone accessed it at some point and has a version maybe 5 minutes old that is sitting there. So and that and, using DNS, using domain name resolution, Based on where you're coming from, it will pick that server and that cache from that server.\u003C/p>\u003Cp>So depending on where you are around the world, if no one's hit it in a in a few minutes, you may get stale content. Stale content, yes, huge challenge. And publishing new content, also a huge challenge because you will spike server resource, meaning it's you don't want to always necessarily be be live, because being live means you are sending a lot of data out.\u003C/p>\u003Cp>Speaker 0: Sure. Sure.\u003C/p>\u003Cp>Speaker 1: It's one thing that we was was common to do is or is like, okay. If I update, you know, if I update this article in WordPress or update this article in in whatever c CMS that I'm using to trigger like a full invalidation. Right? Like Directus. Thank you.\u003C/p>\u003Cp>Speaker 0: I\u003C/p>\u003Cp>Speaker 1: have used directors at at an organization as well. Don't be worried. In in in in in whatever CMS that you are using to just have, like, a blanket, like, asterisk invalidate everything.\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah.\u003C/p>\u003Cp>Speaker 1: Which is a perfectly valid strategy for keeping things up to date if that's, you know, your your, your your your requirement. Yeah. Your But there and there's there's also the requirement then of, well, keeping things up and keeping things, keeping things efficient as well. C CDNs and edge computing are also about efficiencies. We talked a bit about sending requests to your server and that caching level being also a protection mechanism of you not actually hitting your server all of the time.\u003C/p>\u003Cp>So, yes, it's very complicated, and it's kind of still on the engineer's side to figure that out. There are better frameworks to help with this. And as we get closer to real edge computing, there's less whole page caching that we have to do. And this is where we we I kind of wanna transition into well, okay. Well well, why?\u003C/p>\u003Cp>Well, why edge compute? Edge compute means we can run more things closer to the user, meaning, hopefully, we need to cache less. And if we cache less, we could be more live or or we could be we we can have, less individual things that we cash, and the broader interactivity of the website or smaller subsections of it can be more individually individually controlled as to what level of, of staleness we accept within a web.\u003C/p>\u003Cp>Speaker 0: But it's that trade off, isn't it, against, the or, you know, having non stale content ultimately delivered to users and the efficiency gained by being close to them.\u003C/p>\u003Cp>Speaker 1: Exactly. That's it's that's the that's the balance that we're trying to strike. And, really, CDN caching, and at the level of caching whole HTML pages is kind of like is, you know, is the nuclear option. Right? If you can afford to have if if you're a a, you know, a news site, a very, very static type content website where you can you can do things over JavaScript on the client, or, the the content that you're delivering is is very static, then you can afford whole page caching.\u003C/p>\u003Cp>But as as we get close as we get nearer the graph of, right, highly static versus highly interactive or highly, like, live content, like a ticketing experience where you before you go through the booking experience, you need to know you kind of wanna know, okay. Am I going into this? Am I gonna have to make it a whole account and then be told, oh, by the way, it's sold out as it is.\u003C/p>\u003Cp>Speaker 0: Or even or even more, like, personalized experiences like a social media network where we're not gonna full page cache every one of the profiles and every post and every comment that exists. No. No. No. So there's some element of we need to get fresh fresh data as part of this load.\u003C/p>\u003Cp>Speaker 1: Exactly. I mean, how many times are you, you know, just scrolling scrolling up to the top to get your fresh tweets all the time. Right? It's it's, there's a certain amount of stillness a user will accept, and there's also a certain amount of stillness that, the us as engineers or us as whatever company entity that we are will accept with with end users. And Yeah.\u003C/p>\u003Cp>And, and that's that's that's the balance that we're trying to strike. And with edge computing, we are trying to deliver more things or cash listings, and that's achievable in how's that? How's how how do you describe this now? It's a very challenging to describe because we already have compute in in one location. And, moving it closer, just moving it doesn't fulfill, like, kind of the whole stack of requirements that we have, which is we need to deliver quickly.\u003C/p>\u003Cp>We need to be efficient with our resource. We don't wanna just, you know, put things on the edge for the sake of it being on the edge and it costing an arm and a leg, which is one of the concerns you sort of raised as well, which is a a a perfectly normal, you know, objection to this.\u003C/p>\u003Cp>Speaker 0: I didn't even think about the cost. I was thinking purely complexity. But, yeah, of course, there's cost. You're replicating nodes, basically. And the more that happens on those nodes, the more expensive it is.\u003C/p>\u003Cp>I'd not even considered that, but, of course, that's part of it.\u003C/p>\u003Cp>Speaker 1: Yep. And a lot of the the a lot of the current generation, edge compute are serverless pricing models, meaning you are paying for the, there's a there's a couple of pricing models in in this. It's called wall clock time and, and CPU time. One being CPUs, the actual CPU cycles that you consume, meaning you have to write also efficient code to execute. I'll do.\u003C/p>\u003Cp>Otherwise, if you're writing code that is doing weird thing, and there's all sorts of limitations, that exist in terms of what you can do because the run times are also different. When we have a real server, we have any run time that we want. We have any c libraries that we want. We have any language that we want. And a lot of the modern, edge compute locations or edge compute run times because they're also designed to run very, very fast on and not in necessarily, I'll say in air quotes, real service like, real they're not actually real servers.\u003C/p>\u003Cp>They are like a subset of the resources that a that these compute platforms have. So so, again, a couple of the popular ones I mentioned, CloudFlare and and CloudFront. Cloudfront is fronted by, Lambders, but not real Lambders. They're actually a subset of the Lambda runtime, that can only run certain limited amount of JavaScript.\u003C/p>\u003Cp>Speaker 0: What? In an effort to be less computationally expensive?\u003C/p>\u003Cp>Speaker 1: That, but also they've developed from this need of okay. I just need to transform an image very slightly. And over time, we've just kind of put trying to put more and more things in it. Cloudflare is is is a bit more is a lot more advanced. And also the CloudFront one, since I've used it back then, it has got a lot more complicated as well and has gained a lot more features.\u003C/p>\u003Cp>CloudFront have again, it's a limited runtime. It's not node. It is a node compatible runtime, but you don't have access to say every single node library or you don't have access maybe even to the entire node modules, or the entire NPM registry.\u003C/p>\u003Cp>Speaker 0: Oh, is this, is this isolates where it's like pure it's a pure JavaScript runtime with, like, some exposed additional functionality? Because we use those inside of directors, inside of our automation builder. But I didn't know that a lot of the JavaScript creature comforts, things even like console log, things like set time out and things like this, they're not they're not part of Node JS. They're not part of, sorry, the core JavaScript spec. They're part of Node and the browser implementation of JavaScript.\u003C/p>\u003Cp>And you take for granted when these are the 2 really predominant runtimes that we use. So maybe it's something like that where they're using these isolate, environments with whatever additional functionality is exposed by the vendor.\u003C/p>\u003Cp>Speaker 1: Yep. Yep. I I think isolates her was inspired by some of the some of the work that cloud flooded or or may even be a direct, a direct thing from from from Cloudflare. Yeah. Is it a direct descendant?\u003C/p>\u003Cp>But, but, yeah, it's it's exactly that of of we're no longer in the browser. We're very much on a highly efficient, sub resource, that exists far out on on the edges of of these compute regions. And if we if we were to bring up a map, and I'll share share some assets after as well of we we know the general, you know, EU west 2 being London and, US east 2 from AWS being, you know, in Ohio somewhere and your EU West 1 or your or Google's, you know, EU Central 1 in Norway. These are all locations that they have massive, massive, huge data centers with further sub availability zones being, you know, eu west 1ab, e u west 1 c, etcetera. So huge, huge, you know, warehouse sized data centers with tons and tons of servers that have tons and tons of services on them.\u003C/p>\u003Cp>When you additionally look at the map of of, what are the cloud front regions, which are regions where AWS or some other, you know Vendor. Vendor may have, caching locations for, which which are much the smallest subset of machines that they that they control that in partner data centers or in what are called crosslink or interlinked locations where, you know, many vendors, have their servers and, you know, pass cables all over to each other. That's sort of how how the Internet works in that. There's a whole bunch of data centers where eventually cables interlink with each other's data centers. But vendors will have also service in these locations, and these locations are, you know, a lot pricier, a lot closer to the user, and also run much less much much more controlled environments.\u003C/p>\u003Cp>And these are these are these are what we actually refer to. This is what we really, really refer to when we talk about edge locations. We can be close to the user in terms of real locations also in terms of okay. Practically, you sort of want say, if you have a server in you e in US in the West Coast of the US in California, you would also really like a u a a server sort of in Europe ish to serve most of Europe. And then the next optimization is to put them super, super, super close to exactly where, you know, their ISP will interlink and hop over into AWS's domain.\u003C/p>\u003Cp>And that that right there is where we where we actually talk about edge compute.\u003C/p>\u003Cp>Speaker 0: Interesting.\u003C/p>\u003Cp>Speaker 1: So we're putting them beyond server farms going all the way down to kind of the interchanges. And that's all, yeah, we kind of we we put up with lesser resource at our disposal, because also we're sharing with a lot more users or, like, the servers have to serve, you know, many other users, things like that. And, also, because we're so close to the edge and we're doing many other things like fetching and, you know, sending things over the wire as we're streaming. We're we're we're constrained to much more, much faster response times. So Cloudflow, for example, I think you you have to do whatever you whatever compute you do on that edge has to be within, like, half half a second or something or or a second, and you can't do anything more than that, and you get instantly cut off.\u003C/p>\u003Cp>Speaker 0: That's fascinating. So this is really interesting because I thought edge computing was a concept that anyone could apply. It's just the idea that, hey. You know what? I'm gonna spin up resources on these different, you know, servers and do some complex, you know, routing of those.\u003C/p>\u003Cp>No. It really is provided by vendors who are kind of more at that backbone layer of infrastructure. And it's uniquely enabled by being really close to what you're calling these interchanges. That's really interesting and not something I quite understood because it's never a marketing material because it's it's really getting in the weeds.\u003C/p>\u003Cp>Speaker 1: Yep. Edge computing, unfortunately, is a very monopolistic type, very, type of operation because it's not anything that we can get involved with. I I cannot I cannot go and run around and just give people, just put some pies around in server files.\u003C/p>\u003Cp>Speaker 0: Just that. Also, nice sticker. That is a retro sticker.\u003C/p>\u003Cp>Speaker 1: Of mine. Yeah. Because there's there's even more stickers in Slack. I can't afford to go and put these servers around, really, really close to users because I do not own that infrastructure, and I would never have access to that infrastructure because you need a lot a lot of money to be put into these type of locations. Like, you need to be running a network.\u003C/p>\u003Cp>But what you were describing there for just a moment as well of, yeah, just being able to put services kind of vaguely close to users, that is distributed computing, which is different from edge computing. It's both that's an versions of distributed computing are also very important to our goals of of, serving content to users really, really quickly. And this should be a computing and edge computing kind of go a little bit hand in hand as well. Because in in this day and age, at least today, we do have, and you raised at at the head of the show as well, your talk about databases or or data as well. This day and age, we sort of have, an inkling of kind of like the early CDN days.\u003C/p>\u003Cp>We have an inkling of being able to put databases on the edge. But, again, because there's such limited sub resourced run times, it's very, very difficult. So the current generation of databases still lie on the distributed computing layer, which means we our our content can be really, really close to the user. And, hopefully, the content that that little edge computing box is requesting is is kind of like our users are over here, and then the the users of our database being the edge computing nodes, we wanna also be close to those users. So, we need to we need to both balance, where we put the user's content and also where you put the edge computing nodes content.\u003C/p>\u003Cp>Yeah. Yeah. And more often than that, you know, at the end of the day, a website is kind of putting together a whole bunch of database queries. Right? Most websites.\u003C/p>\u003Cp>So if if we can also put the data that is needed to construct that web page close to where it is being constructed, then we have further performance gain. If we can get it if we can get them collocated right next to each other, that's fantastic. And one of the arguments against edge computing always like and you've also mentioned it as well. Why go through all the hassle to need to have this, now we have less environment. Now we have we can't use all my nice libraries, and I have to I have to struggle with, you know, doing things in under 500 milliseconds and whatever.\u003C/p>\u003Cp>Why do I have to go through all these struggles when it's good enough if they can just access my already distributed you know, I've already put a node in Europe, and I've already put a node in the US. That's good enough. And it comes down to what is the quality that what is the quality experience that we are aiming for? Are we aiming for near native, or, is, you know, is good enough good enough? I am a firm believer in it's the world wide web, and it's not the US web.\u003C/p>\u003Cp>And there was a time, Guillermo Rauch, kind of pioneers a little bit now with with Vercel, and their efforts in in edge compute or or delivering good UX as well to developers for for engineering on these new new run times. I've read the tweet of him once of in the early days when he was setting up Vercel or, whatever it was called back in the day. Zite. Zite. Zite.zite.co.\u003C/p>\u003Cp>Whenever he's setting up zite.co and he first went to the s went first went to San Francisco, he's like, oh my god. The Internet's so fast over here because that's just where that's just where your your data center starts is in the US. And then good luck when you finally if you decide to put a server somewhere in Europe and we get access to some slightly faster websites. And And at the end of the day, we are talking slightly faster here and there in a lot of cases because our undersea cables between, you know, Europe and the US are pretty fast. If I was to put a data center in Oregon, and we can do we can do this this is one thing we can do.\u003C/p>\u003Cp>We could do a little, ping test as these sites that can ping across all the data centers. If you if if you do a ping test into Ohio, it's about 250 to 300 milliseconds of round trip time. Vaguely okay for most for most use cases. It depend\u003C/p>\u003Cp>Speaker 0: it depends how resource intensive your application is, I suppose. If you're starting to build something that's really, really bandwidth intensive, multimedia site, actually, it starts to matter a lot more.\u003C/p>\u003Cp>Speaker 1: Yep. Multimedia if just even just a normal website. That's that's that's kind of fine for Europe. Right? But, again, we're not the worldwide web of US and UK.\u003C/p>\u003Cp>We're the world wide web. And imagine having being in Australia or being in South Africa or being in India or being in China, and having 800 milliseconds to 1.2 seconds of round trip time. And that is round trip time meaning on literally anything that you do. So first, there's and in modern web applications, that is alright. First load HTML.\u003C/p>\u003Cp>1.2 seconds just to get the first request going with streaming HTML, then it hits some JavaScript that he has to go fetch. And that's another 1.2 seconds of doing that. And that's that's just the round trip time, not only you then have to be downloading through that entire time. So it's it really compounds the more that's going on. And when we're aiming for native like snappiness, the goal the goal is native like snappiness with edge.\u003C/p>\u003Cp>And if the the the point is we need to get things really, really close to the user for that initial load. Humans, there's a psychological, element to slowness or to to delivering fast experiences. And if we can show things quickly, it doesn't matter as much how long it actually takes to then deliver things as long as something's happening. There's actually an interesting UX that exists today in AI because, there's this new UX pattern now of streaming text Oh, yeah. Which we didn't have a year ago.\u003C/p>\u003Cp>Speaker 0: The the data physically doesn't exist when that when I start getting a response. It's yeah.\u003C/p>\u003Cp>Speaker 1: And you you you imagine if if if we didn't have that u that UX only serves the purpose of AI being too slow today. Imagine us having to wait a full 10 seconds for us to get the full kind of page back of the AI response. That it that that would be an extremely frustrating human UX experience. But just by the fact that it's actually coming in character by character, you think, oh, shit. That was really fast.\u003C/p>\u003Cp>Because you you actually you're reading you and you're consuming. And that is the UX that edge computing is trying to tackle of. And having having a risk response back instantly and having your content just there straight away.\u003C/p>\u003Cp>Speaker 0: Could I ask a question? When you were talking about the, the concern I had around the effort that needs to go in, the effort you described was all about writing performant code in a more, in a more limited environment. But I ask, what is the actual work involved in setting up edge applications beyond just writing code that will run? Do I have to manage where stuff is, or do I basically just, like, fling it up to a vendor and they take care of the of the distribution of that? Like, is there is there work required to physically make it edge code that will run on the edge beyond the environment and beyond the, the performance requirements?\u003C/p>\u003Cp>Speaker 1: There is a gradient. There there there is there is a gradient of of effort that can be spent here. And every sing every single day, there are new there is more and more tooling that makes it easier. As a baseline, anything you do in AWS will be hard because they are a platform. Right?\u003C/p>\u003Cp>They're they're just they they are they are infrastructure of a service. They're not the platform, and they're not the tooling. They are they have other services on top, like, you know, your, whatever they call their their stuff.\u003C/p>\u003Cp>Speaker 0: Amp Amplify.\u003C/p>\u003Cp>Speaker 1: Amplify. AWS Amplify are sort of some of those toolings that do distribute compute. Google Cloud, also, it's gonna be hard, but they have other services built on top. They have things like Cloud Spanner is their distributed database. Really, really fun if you read their white paper on on Cloud Spanner.\u003C/p>\u003Cp>It's it's a very googly white paper, and it's very very overcomplicated thing. And they talk about syncing satellites and time clocks in servers across the planet and how they use this network of satellites to have, like, microsecond time precision is very interesting read. Highly recommend. There's things like that. And there's Firebase on top, which also does distributed computing.\u003C/p>\u003Cp>And so there's, so there's frameworks built upon these things that that that make it easier. And ultimately, it comes down to it to frameworks or other platforms that make it easier as we go up the stack. Vercel also are a platform, but they make underneath you know, they they use AWS Lambdas. They use Cloudflare edge workers.\u003C/p>\u003Cp>Speaker 0: Mhmm.\u003C/p>\u003Cp>Speaker 1: And that's sort of where if if you've ever experienced working with Nest, which is, again, kind of another superset on top of Vercel, because it just kinda uses all of Vercel features. When you are working in a an edge nest route, you have a limited amount you have a subset of things that you are able to sort of do from from the from the platform Sure. Because it's running it's no longer running on a Lambda, which is a 4 Node JS instance. It's actually running on a Cloudflare Worker, which is that isolate that you just described. So they are tooling.\u003C/p>\u003Cp>There is tooling that makes it easier. And then in other realms, in databases or in CDNs, there's more tooling there as well. There's there there's such tools like, PlanetScale is becoming very popular these days with its easy distributed computing of or easy distributed computing of databases. And there are other things that are trying to actually put databases on the edge, and the current kind of front runner for that are, SQLite, which actually Cloudflare again, another pioneer in this area. KV, key value store, is a product that is built on SQLite.\u003C/p>\u003Cp>Dino, have a KV, a key value store. Again, kind of built not on SQLite directly, but a fork of it that does this distributed computing. A whole bunch of startups doing SQLite type distributed databases. Edge actually, edge database. Not only distributed, but actual edge\u003C/p>\u003Cp>Speaker 0: On those edge nodes. The how does syncing oh, sorry. What I'm basically hearing is vendors more or less will take care of the of the distributing of your assets, whatever those assets are across nodes that they make available. That's not something I necessarily need to do. If I don't care about edge, if I just care about distributed, it's something I could do with great pain.\u003C/p>\u003Cp>Yep. I or I imagine there's tooling still. But a lot of these vendors will just take care of that. That's part of the offering. What about syncing stuff?\u003C/p>\u003Cp>Surely, there's some trade off around, you know, even if it's the data store is what I'll call it over a database. The data store, the cloud, you know, the cloud functions that run the edge functions, and all the assets and stuff like that. How do they all stay in sync? Obviously, when I push an explicit update, I imagine there is an explicit, you know, propagation of that of the updates. But just day to day, I\u003C/p>\u003Cp>Speaker 1: Mhmm.\u003C/p>\u003Cp>Speaker 0: I'm a user. I add an item to a data store that happens near me. How does it get to everything else? And is there a risk involved that things will start to fall out of sync?\u003C/p>\u003Cp>Speaker 1: Yep. Certainly. Now the for the KV stores, for the for the SQLite stores, I've really not read up enough about what's going on there. It's like mind blowing stuff that goes beyond my comprehension right now. So I have no idea how they sync because, also, SQLite is a binary data format.\u003C/p>\u003Cp>So it's it's mostly if anything, I believe it's kind of for, like, edge caching or some sort of be able to write small things. I don't I don't know how it gets back to your main server. Crazy crazy black magic over there.\u003C/p>\u003Cp>Speaker 0: Sorry. Can I pause you? Your main server. So, in all of this, there's still a main server running that\u003C/p>\u003Cp>Speaker 1: You could. You could. Or at least, you you you definitely could write you kind of have to flip how you how you develop. If you wanna be entirely edge, you certainly can. And a lot of use cases don't really fit into just being entirely edge.\u003C/p>\u003Cp>Mhmm. Even with, say, Vercel, for all their efforts in doing, distributed computing, or edge computing, when you actually log into your Vercel instance, there is a drop down that you could actually pick your main location that it that it puts. Interesting. It's, it still needs to run that Lambda somewhere in some AWS data center. So there's still a a a main place that you're actually doing real compute.\u003C/p>\u003Cp>You can definitely, if put with a lot of effort, build entirely edge, services, but there will be points at which you need to escape from that to build, to have the full, you know, a company of of real runtime. Sure. And any other any other service that you might need to inter interconnect with, like any, like, queuing system or whatever or and any any real app that is doing something more complicated than just serving a website is gonna need other resource that cannot be run on the edge. And, honestly, it doesn't necessarily even need to run on the edge because we can get you know, there there is, like, the liveness of the website and your interactivity. And then there may be other things that you need to do in terms of, you know, workers or sending batch emails or, you know, do doing other compute or, like, you know, on YouTube scale, like, you know, upload a video and you have to transcode it and all that.\u003C/p>\u003Cp>So there there there's there's always other things that you may need to do in a in a business to serve whatever use case that your business is serving, but the the, serving of a website can kinda be isolated down to, you know, this edge thing.\u003C/p>\u003Cp>Speaker 0: That's but that's fascinating. I never thought about that. Edge is like a is like one of the tools in a wider application. It's not I it's not application that's very traditional or perhaps distributed or whatever, but it runs properly. And then elements of this application are run on the edge that benefit from the, from the characteristics of running on the edge.\u003C/p>\u003Cp>That is something that has never quite I never knew that. That's really interesting. But is it fair to say that that core application has to coordinate the edge nodes? Is that what you're what you're thinking? Because you said because you were talking about stuff going back to your main application.\u003C/p>\u003Cp>Tangent.\u003C/p>\u003Cp>Speaker 1: You you you you could. And I and I think it's it's really clicking with you when, earlier when I was describing, you know, just delivering full page versus those small elements of it, and it's like and it's kind of exactly that. But in terms of coordination, you know, this this then gets into, you know, microservice distributed computing type deals of, like, okay. They they can be isolated in their own way and, more was more referring to when sending things back is kind of the data that the user may may have input. So user input or, you know, if they're chatting away, if they're interacting with if they purchased a ticket and writing that back to the source of truth that ultimately, there must be a source of truth somewhere.\u003C/p>\u003Cp>Ultimately, some database needs to know that, look, the tickets were a 100, and now they're 99 available. Someone needs to know and be written back to, and that's what I what I'm referring to when I say, okay. Eventually, get back to\u003C/p>\u003Cp>Speaker 0: Got it.\u003C/p>\u003Cp>Speaker 1: That that source.\u003C/p>\u003Cp>Speaker 0: Got it. Got it.\u003C/p>\u003Cp>Speaker 1: And there's many strategies that we can employ on that source of truth because we can we can have a distributed source of truth. Kinda this Cloud Spanner database from Google, which kinda came out, like, 8 years ago, and that that white paper was making its rounds in distributed computing land, was really, really exciting because it sold it was trying to solve the problem of multi node writers. It's a challenging databases today to have multiple, multiple writer nodes. So current current database technology relies on having a single writer with multiple read rep. So you can you can you can replicate readers all day long because it's easy to, and sort of the the whole theme of this conversation has been it's really easy to replicate, caching content, so replicate reading content, but it's very, very hard to replicate writing or updating content or Absolutely.\u003C/p>\u003Cp>Invalidating. So it's always been very easy to do low latency writes with low latency read replicas where, you know, you might have, you know, those, you know, basic basically, the the ping between 2 servers be your latency from from read write replicas. So you may say and it and depending on your use cases, it may be acceptable that, okay, Europe is, say, 500 milliseconds behind US. So if you were to go to a website, technically, you would be seeing 500 millisecond, stale content, and that may be acceptable. But it may in terms of fairness of the Internet or the World Wide Web and not the UK, US Web, It's unfair to set to always put an advantage on, your your geological, position.\u003C/p>\u003Cp>So, technically, or, and I think that there there was an article once upon a time around when the Cloudspana or one of the Cloudspana customers originally was Ticketmaster. And their particular use case was this sort of fairness topic of well, okay. Australia will always be 1.2 seconds behind everybody. So if they go to book a ticket and someone literally just, you know, 1.2 seconds closer to the server clicks it, they will always win. So it's unfair to put people at this kind of dispute disadvantage.\u003C/p>\u003Cp>So we're trying to build technologies that distribute these rights more evenly, and you can get kind of more fair distribution of of updates.\u003C/p>\u003Cp>Speaker 0: Yes. Ticketmaster, the bastion of fairness. Sorry. Please continue.\u003C/p>\u003Cp>Speaker 1: Well, in in in reality, what they actually want is, you know, more they can cash less and not have this this, queuing system, which which leads to more clicks, more purchases. Right? That's that's that's the end goal. That's the end goal with all of this. There's well documented stats about how Google goes about about web performance on the web.\u003C/p>\u003Cp>And, you know, if you're x milliseconds slower than a competitor, you know, you're more likely to drop off and just go to the next site that is faster. So while us as engineers, we wanna over complicate our life and do fun complicated engineering things, Us as business people, we wanna deliver things fast because it yields greater returns and is a better native experience and will yield happier users. That's ultimately the goal that we're trying to trying to solve, while also doing it more cheaply, hopefully.\u003C/p>\u003Cp>Speaker 0: Or at least over time. So a question for you then. In the current state of edge computing, what are people actually doing on\u003C/p>\u003Cp>Speaker 1: the edge beyond what, you know, what was once possible with, you know, just CDNs? What people what the most trendy thing now is we are rendering HTML on the edge. We are rendering websites closer to users. And what I mean by rendering websites is we are rendering more interactive content next to the user. So no longer are we constructing the whole webs web page, you know, 800 milliseconds away from the user and then delivering that over the wire.\u003C/p>\u003Cp>We are constructing it closer, meaning all the other subsequent calls that we might have to make to other services, are hopefully also calling services also closer to that edge region. So it's it's more and more, companies are putting more and more of their own services in more locations. Sure. So say, let's take an example of I wanna construct a web pay a Shopify web page. Shopify have a fantastic global API network.\u003C/p>\u003Cp>I argue that actually Shopify have the most distributed database on the market because actually, you know, when you update something in Shopify, it's already distributed to their network of of of re replicas around the world. If I was to construct the data there, and then, okay, I also call out to another service that I control, or I also call out to, like, another partner API. If we if we request that, make a request there, and it goes 800 milliseconds to wherever it was being constructed, and then that that does its course and it comes 800 milliseconds back, that's, you know, 600 a 1.6 second round trip or whatever. If we take that request and say put it right next to the user and go, okay. As soon as it comes in, I'm instantly streaming back.\u003C/p>\u003Cp>So it's close to the user, say, 20 milliseconds away. Generally, edge location is a sub 100 millisecond close to the user.\u003C/p>\u003Cp>Speaker 0: Good to know.\u003C/p>\u003Cp>Speaker 1: So they they hit it. Instantly, they get back, you know, they white page with loading things, and it goes, okay. Slows this. Okay. Now I need to grab some stuff from Shopify.\u003C/p>\u003Cp>I've done a request to Shopify back and forth. Hopefully, they're also at edge location, 20 milliseconds back and forth on my edge. I've got my Shopify content. Oh, I'm doing an AB test. I've hit my AB test service.com, and I've got back the result of what needs to happen.\u003C/p>\u003Cp>And, okay, I've loaded that content. And it's this it's this dynamicness that we wanna put closer and closer to the user because if we were\u003C/p>\u003Cp>Speaker 0: to And it and it compounds. Yep. All of these 800 millisecond round trips are grueling, but a bunch of 20. I mean, of course, you still wanna be mindful of how many you're doing, but that's the same in any web application. But we're talking orders of magnitude quicker realistically when you're loading any modern web application.\u003C/p>\u003Cp>Speaker 1: Exactly. Yep. So it's it's it's more it's more of this dynamicness because we could totally just off cache that entire page and delivered it to all the users equally. But what if one one user is logged in, one user has a basket where they, that that that we wanna also display and and render on the server? We could totally render it on the client, and this is where also this new modern trend of, you know, it was very it was perfectly fine to deliver entire huge bundle to the user and it be interactive and do API calls on the client side because the client side is also an edge location.\u003C/p>\u003Cp>Sure. But we pay for the upfront cost of them receiving that bundle. So if we can\u003C/p>\u003Cp>Speaker 0: That's interesting. Yep. So it's that trade off still of speed. We need to deliver a a reasonable experience as quickly as possible. Then, ideally, we want all subsequent requests to be as speedy as possible.\u003C/p>\u003Cp>But if, you know, if this is where we're starting to pay a little bit, that can be more acceptable dependent on user and kind of, developer experience or, like, you know, vendor experience requirements. Exactly. That's really interesting. So it's just this trade off of of requirements. I feel like this, you know, edge computing starting to gain some traction is bringing a whole new realm of, I don't know what to call that requirement gathering, like, trade off decisions for developers who didn't need to care as much about infrastructure before.\u003C/p>\u003Cp>And now suddenly, the same way front end developers now have to do a bunch of back end work with these kind of mixed hybrid frameworks that run everywhere. I feel like in the in the same way, anyone who does back end work is now having to care about infrastructure in a way where perhaps the the expectations in the past were less than. Yep. And then it's the job of these vendors who who run edge nodes to make that experience as contain as little pain as possible.\u003C/p>\u003Cp>Speaker 1: I think I think you've hit the nail right right on the head there is, we we've we've this this trend is the flip side of is is the next evolution of SPAs, of single page web apps. So that was our edge in the past, and that was our limps limited subset runtime. We could only run JavaScript, then we could only run web JavaScript in that runtime. And, what we're having now is that it's a limited run time, yes, but there's we have more languages, more things that we can run closer to the user, and it's we're delivering them. We're not using the user's resource.\u003C/p>\u003Cp>Right? So a a lot of SPAs or a lot of, mid 2000 in the Internet relied on, you know, fast devices or, you know, doing a lot of read writing of, you know, the DOM tree and all this, and then lower, lower quality devices with less CPU, like dumb phones or or or or basic Android devices had, you know, a worse experience on the web. And what we're trying to deliver is by doing doing the complexities of the HTML rendering and whatnot close to the user and delivering them, you know, the content that just needs to be rendered and device can become dumber again, and need to do less, you know, JavaScript execution on the client. Because, really, all we all we actually want at the end of the day is to deliver that HTML to the user. And that liveness, that interactivity used to come from or used to only be able to come from SPAs, client side JavaScript.\u003C/p>\u003Cp>And what we're seeing today is that we're moving more and more of that client JavaScript onto the server, but also quite close to the user to be kind of that native like experience.\u003C/p>\u003Cp>Speaker 0: And that and they're the parts they're the parts. It is we want to make the users do as little computation as possible while not, suffering based on their location. The fact that a load of that computation is going to happen elsewhere. And it's that specific pairing of of requirements, that makes edge com that makes distributed computing more powerful and even more so edge computing because they run right at those interchanges. That's that's great.\u003C/p>\u003Cp>Now, for some of the other episodes of, learning things I love to hate, we went into a demo, but I feel like we've covered a lot here. I don't necessarily think we need to we need to do it so much. Plus, it's a really abstract concept where, you know, I'm sure there are ways, but it isn't gonna be now it's running on the edge, and we can really show that to its fullest. But I think I understand a little more why why edge computing is interesting now. Some more or less basic concepts about how it works when it also might not always be right.\u003C/p>\u003Cp>And this new idea that, oh, no. It's just parts of your application you can delegate to the edge. Again, not something that is spoken about by the hype machine very often.\u003C/p>\u003Cp>Speaker 1: Yep. It's just edge edge\u003C/p>\u003Cp>Speaker 0: edge edge all the time.\u003C/p>\u003Cp>Speaker 1: Just parts. Just parts. Right? And we we we have the we have the same mistaken view of serverless computing, in the past where it was like, okay. Now everything must be serverless.\u003C/p>\u003Cp>Mhmm. No. It's a subset of use cases that are that that benefit from it, and that's the it's the same with the edge. It's not we don't wanna put we don't need to put the entire server close to the user. That's impractical.\u003C/p>\u003Cp>But elements of it definitely can. And, and, yeah, and I think the the the the the reason it's so abstract in this way is it's hard for us to experience what other people are experiencing when we're in our, you know, our our nice modern MacBook on gigabit Internet in countries with good Internet. So it's it's hard to put us put ourselves in those shoes. And, the way we used to do that with SPAs and stuff is literally have a crappy old Android phone for dev that you would, you know, every so often look at and use. And we can replicate that if try try the web on a, on a VPN every so often.\u003C/p>\u003Cp>Or if you're in a foreign country, try going to some of your favorite websites and just seeing how much slower they might feel. Because, yeah, it's it's\u003C/p>\u003Cp>Speaker 0: conjured up a memory of a it's slightly off topic, but you've just conjured up a memory of in London, Mozilla used to have an open community space, and in that, they had what they called the Mozilla Device Lab. I imagine there\u003C/p>\u003Cp>Speaker 1: were a few of them, and\u003C/p>\u003Cp>Speaker 0: it was just a bunch of different devices. Or, like, they run they run browsers which are, you know, really, really, really limited with this exact idea that you could be testing on all these different devices. But, yeah, now we need to consider and I suppose that's the other part here. What edge computing enables is less computation happening on a user device, so it's lowering the needs on the user device, and it is making that computation closer. So we're kinda leveling the playing field.\u003C/p>\u003Cp>It's this fairness, as you mentioned earlier, of you don't need the best hardware, and it doesn't necessarily matter where in the world you are. Both of those factors are handled by this new emergent technology.\u003C/p>\u003Cp>Speaker 1: Exactly. Exactly. And it's it's it's all it's all right as rain for us to talk about fairness, but at the end of the day is we want to have users around the world because we're hitting we're hitting more ability for us to sell to more users. And at the end of the day, that's really what we're trying to solve with with edge computing because get more and more users with more and more happy users because we can have users that are unhappy, but, really, we wanna have more and more happy users.\u003C/p>\u003Cp>Speaker 0: Yeah. Awesome. Thank you so much for joining me. This has been really, really interesting. I'm loving filming this series.\u003C/p>\u003Cp>I'm learning tons. And hopefully people who have joined us for the ride also, are learning loads. Just before we go, is there anything else you wanna share, point people to where to find you?\u003C/p>\u003Cp>Speaker 1: Sure. I mean, if you want if you wanna see more of, like, crazy drawings on my Twitter, I'm I'm at Pandeliszed, p a n d e l I s, zed, on Twitter. It's it's funny when I was drawing that in the office because we we kinda sit in a bit of a semicircle, and my colleagues turned around and were like, what? How are you doing? I'm like, oh, just drawing.\u003C/p>\u003Cp>Just drawing some stick figures. I was like, okay. Fine. But, yep, that's that's that's where my normal antics are or on Twitter. And, and yeah.\u003C/p>\u003Cp>No. I'm so so happy, that you had me, Kevin, and it was, I I saw your brain clicking at the end there. So I'm so glad that I could I could share that with you, and, hopefully, it's it's no longer anything that you that you hate.\u003C/p>\u003Cp>Speaker 0: It is not something that I hate. I have, a newfound like other episodes, a newfound appreciation and more importantly, an understanding of the qualities. Right? Which mean that it may be something I reach for when appropriate. Whereas before, I just lacked the knowledge.\u003C/p>\u003Cp>So I was never gonna reach for it. And, you know, in time, that could lead to me building things that aren't as good, as they could be. So, yeah, thank you ever so much. Thank you to everyone who has joined us, and, we will see you in another episode of learning things I love to hate. Bye.\u003C/p>","Hello, and welcome to learning things I love to hate. This is a show where I basically stop putting off learning things that I have avoided for one reason or another, inviting in my friends and experts around the topics that I'm trying to learn. And today's topic is edge computing, a topic which has got a little spicy in web circles in the last few weeks. I'm inviting my lovely dear friend, Pandellus, here today. Pandellus, would you like to introduce yourself? Yeah. Hi, Kevin. Nice to see you again. Yeah. I'm I'm Pandellus. I've been an engineer for the last few years working in web, working in in deploying a lot of the things that I claim to write. I've worked in web agencies where delivering content to users was super, super important. Back in the jQuery CDN days where when edge computing was basically only CDNs into kind of our modern edge computing world now where we can put entire runtimes, entire databases onto the edge. There's all things I've experimented with at various companies. So I I'm so happy when I saw your tweet. It's something I've been experimenting with a lot. And, as someone as a user of the web, I think it's something super important for for everyone to to to to to know about and experiment with. Awesome. And, and yeah. So I tweeted out a few days before this recording. Can anyone just, like, explain edge computing to me? Because I really don't understand it. And you came in with a wonderful set of illustrations, which actually will just edit in here right now. These are the illustrations, to kind of explain a little bit about how Edge works. So I thought, hey, I'm just gonna invite you onto this show. This was already a topic I was planning on talking about. You preluded, I suppose, some of the things I wanted to discuss today. So just to just to open with this, I wanted to explain kind of where my knowledge is now, and hope that you might be able to take me and anyone watching who's in a similar spot through that journey of understanding more. And perhaps if we have some time at the end, we can do a little demo of this abstract concept. So what I know of edge computing, I think, really is around content delivery network, CDNs. We can maybe start a little bit about talking about this. And I know that the concept of what can be stored, you know, and replicated in multiple regions and serve to people based on where they are in the world has just grown more complex. We we're doing that with more things. And I suppose my biggest concern and the reason I haven't really done it yet is, 1, the idea that, you somehow need to replicate things really rapidly in lots of regions. And 2, unrelated, it just seems really complex, and I'm not sure how how much the complexity is worth, what might be a payoff that doesn't matter. I know there are some performance hardcore people who are like, of course, it matters. But, yeah, that's kind of my starting point. So maybe if you take us back, talk a little bit about CDNs and what they are and kinda how that's evolved to where we are now, that would be really good. Yeah. Of course. Yeah. No. I mean, as engineers, we like to make our lives harder for sure. It's it's it's we we we do sometimes like to like to overengineer, and it and it's all as with everything in engineering, there's a million ways to do them. Not all of them are right, and a lot of them are right. So your mileage may vary with your needs of edge whatever. A lot of people don't even need the CDN, but it comes down to your users. Right? It always comes down to your users and the experience that you're trying to deliver. So let's let's start with CDNs, and what is the problem that that that CDNs solve? So if we go back to the mid 2000, when jQuery and, you know, serving libraries over the wire were were were all their age, we would, you know, blindly go to, CDN stack or whatever those CDN websites were and grab URLs for for jQuery and put them in our sites. Before build systems, before your web packs, before the the the modern JavaScript ecosystem back in days, CDNs were all their age because we wanted to deliver large JavaScript bundles to the user quickly. Internet was slower, and still is slow. Or this is h t p one days, right, before streaming h before multi, you know, multiple h t p two streams, and all that type of stuff. So it was very important or we people saw a lot of gain in having these large JavaScript bundles close to the user, meaning the end users could consume that JavaScript faster. And in the end, what that means is when they get their HTML through, it becomes interactive faster. Could I ask you a question? Could I pause it? So when you're saying near to where people are, just to clarify, we mean that this one jQuery bundle or whatever is stored on multiple servers throughout the world. I request it via one URL, and then the application which will serve up that file will find the place nearest to where I'm making the request and serve it. And then the additional benefit of CDNs, I suppose, is if I visit 10 sites that all are trying to load the same large bundle, this might be more CDN specific, and I think it also might be a relic of the past, but it it would not It is a relic of the past. That's that's that's one of the topics I was gonna touch on. In in the early days, it was when there was less CDNs around, we we could make the ex we could make the excuse that, okay, by using a shared CDN or, say, a common example was also Google Fonts. Mhmm. By using Google Fonts, by using a common CDN, it means that there's a higher likelihood that a user would already have those assets on their computer. Cached. Okay. Exactly. So it's a further cache. Ultimately, the the most edge location is the user's computer. So caching is always a tiering system and CDNs are a type of cache, and the ultimate caching is local. When you have a local cache, that's that's the ultimate edge. And really with edge compute, with edge with with the topic of delivering on the edge, what we're trying to achieve is native like performance, and the most edge you can get is being on device. So, arguably, the the most edge computing delivery method today is an app. Apps are on your device, and there's no more edge than the the the device that you're touching. And everything that we're doing on the web or or in edge compute land is to try and achieve native like performance. Cool. That makes sense. So, yeah, those are those are sort of CDNs, and that is kind of the the most basic form of putting things on on the edge that we had. So that and that was, and there was a legitimate benefit to to to to CDNs. And what we've tried to do in or what has happened in in the modern era is CDNs themselves have become more and more capable, to the point where they can actually run and execute code. 2 of the most popular and, CDNs around are are CloudFront from AWS and, Cloudflare. And Cloudflare are one of the pioneers of of edge computing as well, and their CDN offering just over time naturally has become more has gained features, has had feature creep, and eventually, we wanted to do more complicated things over time. Right? We we may wanna deliver a slightly different version of a bundle for certain users. Or if it gets hit with a with a certain URL parameter, we might wanna bust the cache or or run some sort of, run something on that server that's delivering it, maybe do an AB type test, where certain users got certain bundles or whatnot. So at some point transformations as well? File transformations became yep. Image image CDNs. So moving from kind of just JS bundles, image CDNs are, again, super popular because, on super useful because, the the 2 largest assets that get delivered are the bundle and the images. And images also very bandwidth intensive and benefit largely from being closer to the user. Sure. And we're gonna we're gonna say closer to the user a lot throughout this conversation. And what that what that practically means is that you are spending less time in flight over cables. Your server could be very far away. And the further away it is, the longer it will take to navigate, you know, the the, the the sea of cables that live under the sea, to get to your user. So the closer you can be, the less hops we can make, the the the the the better for for the end user, but also for our bank, CDNs, specifically, not necessarily edge compute, but CDNs, specifically, also benefit benefit us in that we send less data out because it's also a caching mechanism. Edge compute, not so much when we when we get when we get down to it, because one of those goals is to have as fresh content as possible. So when you're when you're when you're caching, you're limited by the freshness that you can deliver. So that that's that's sort of that that's sort of the niche that CDNs sold for a while. And, yeah, more and more doing more and more things on the edge or closer to the user or doing more compute at the CDN level means that we could do these kind of transformation things that you just mentioned with images. Right? So say I wanted an image 30% smaller, we could deliver 1 all the way back from our original server, or we could use the kind of already existing cached asset and do some computation on it and then also cache that. And that's this kind of level of level of tiering that that that being closer to the user kind of offers us is is we don't wanna keep hitting our main server, and wanna keep delivering faster things to the user because, yeah, it's all about speed at the end with with with the goal of edge. Cool. So now we're in a space where it's not just about storing assets, whether that's bundles, images, you know, media, whatever. It's actually about running computational tasks at the edge. So I suppose, naturally, that moves us on to maybe what what is edge compute edge computing? What is it capable of now? And then I suppose we're going back to my initial concerns or skepticisms. 1, how do you keep all of these nodes? I don't know if they're called nodes. I'm assuming they're called nodes in in sync, especially when you gave an example of, you know, doing transformations at the edge and then caching that. Well, is the cache just at a node level? Do they propagate throughout a network? Stuff like this, I'm not too sure about. And then it sounds really complex. How how does this actually shake out to being something that's tolerable to developers? Yeah. Edge and the and this this edge cache or caching cash busting, in CDN land, it has always been a pain, especially in the days where I was working as at a web agency. So, basically, all all all that we deliver over the wire is is assets and and JavaScript and images, and it was definitely always always a battle of, okay, well, what is actually being delivered to the user and cache busting it and and and figuring out, oh, okay. Oh, they're on an older version of the of the site, and they're seeing old content and it and us getting rang up by our clients being like, the other site that we just published it. It's not gone live, and that's having to explain. Okay. You're gonna wait for the cache to propagate. It's it's gonna it's gonna get to the your user eventually. No. But we've we've launched this because, some context here. I used to work in, theater websites, where we had very peak peaky demand spiky demand and very, and certain requirements around, you know, if a certain show went live, they want it live now so that people can book it now. Which is not an unreasonable expectation if I hit publish that I mean, that's even the thing with, like, static website building. There's always a build period, and some people don't get that that build period, you know, is can be quite material. Yep. And that is also that's a huge challenge now with edge compute as well, but and also at the time with CDNs as well because we are we're still trying to we're managing demand, and we're managing speed. And the most fast asset we can deliver to someone is something that's cashed. So there's always a challenge on how you distribute or revalidate that cash. So in the CDA, it's so it's definitely I'm not gonna say it's anything that that's that's easy or perfect. It's a challenge at every level no matter how simple, even at the simplicity of image and and bundle cache, but also to the level of, of full HTML page cache. Right? So during during go during, say, ticket sale go lives or or certain events, we may sort of cache entire web pages, and that becomes incredibly complicated to deliver to many, many users because we then have the challenge of say, okay. What happens when the tickets now run out? And everyone should be seeing a, you know, sold out banner. And, depending on where you last were when that cache hit that node Yeah. And the the the way the way cash is generally work is, you know, it's a pass through cache, meaning, the CDN is the thing that will ask your server, make the request to your server for content, receive it, stream it back to the user, and also save a version on on that server. So depending on who access it at what time, there will be a cache with a certain time to live of 5, 15 minutes a minute. So meaning someone accessed it at some point and has a version maybe 5 minutes old that is sitting there. So and that and, using DNS, using domain name resolution, Based on where you're coming from, it will pick that server and that cache from that server. So depending on where you are around the world, if no one's hit it in a in a few minutes, you may get stale content. Stale content, yes, huge challenge. And publishing new content, also a huge challenge because you will spike server resource, meaning it's you don't want to always necessarily be be live, because being live means you are sending a lot of data out. Sure. Sure. It's one thing that we was was common to do is or is like, okay. If I update, you know, if I update this article in WordPress or update this article in in whatever c CMS that I'm using to trigger like a full invalidation. Right? Like Directus. Thank you. I have used directors at at an organization as well. Don't be worried. In in in in in whatever CMS that you are using to just have, like, a blanket, like, asterisk invalidate everything. Yeah. Yeah. Which is a perfectly valid strategy for keeping things up to date if that's, you know, your your, your your your requirement. Yeah. Your But there and there's there's also the requirement then of, well, keeping things up and keeping things, keeping things efficient as well. C CDNs and edge computing are also about efficiencies. We talked a bit about sending requests to your server and that caching level being also a protection mechanism of you not actually hitting your server all of the time. So, yes, it's very complicated, and it's kind of still on the engineer's side to figure that out. There are better frameworks to help with this. And as we get closer to real edge computing, there's less whole page caching that we have to do. And this is where we we I kind of wanna transition into well, okay. Well well, why? Well, why edge compute? Edge compute means we can run more things closer to the user, meaning, hopefully, we need to cache less. And if we cache less, we could be more live or or we could be we we can have, less individual things that we cash, and the broader interactivity of the website or smaller subsections of it can be more individually individually controlled as to what level of, of staleness we accept within a web. But it's that trade off, isn't it, against, the or, you know, having non stale content ultimately delivered to users and the efficiency gained by being close to them. Exactly. That's it's that's the that's the balance that we're trying to strike. And, really, CDN caching, and at the level of caching whole HTML pages is kind of like is, you know, is the nuclear option. Right? If you can afford to have if if you're a a, you know, a news site, a very, very static type content website where you can you can do things over JavaScript on the client, or, the the content that you're delivering is is very static, then you can afford whole page caching. But as as we get close as we get nearer the graph of, right, highly static versus highly interactive or highly, like, live content, like a ticketing experience where you before you go through the booking experience, you need to know you kind of wanna know, okay. Am I going into this? Am I gonna have to make it a whole account and then be told, oh, by the way, it's sold out as it is. Or even or even more, like, personalized experiences like a social media network where we're not gonna full page cache every one of the profiles and every post and every comment that exists. No. No. No. So there's some element of we need to get fresh fresh data as part of this load. Exactly. I mean, how many times are you, you know, just scrolling scrolling up to the top to get your fresh tweets all the time. Right? It's it's, there's a certain amount of stillness a user will accept, and there's also a certain amount of stillness that, the us as engineers or us as whatever company entity that we are will accept with with end users. And Yeah. And, and that's that's that's the balance that we're trying to strike. And with edge computing, we are trying to deliver more things or cash listings, and that's achievable in how's that? How's how how do you describe this now? It's a very challenging to describe because we already have compute in in one location. And, moving it closer, just moving it doesn't fulfill, like, kind of the whole stack of requirements that we have, which is we need to deliver quickly. We need to be efficient with our resource. We don't wanna just, you know, put things on the edge for the sake of it being on the edge and it costing an arm and a leg, which is one of the concerns you sort of raised as well, which is a a a perfectly normal, you know, objection to this. I didn't even think about the cost. I was thinking purely complexity. But, yeah, of course, there's cost. You're replicating nodes, basically. And the more that happens on those nodes, the more expensive it is. I'd not even considered that, but, of course, that's part of it. Yep. And a lot of the the a lot of the current generation, edge compute are serverless pricing models, meaning you are paying for the, there's a there's a couple of pricing models in in this. It's called wall clock time and, and CPU time. One being CPUs, the actual CPU cycles that you consume, meaning you have to write also efficient code to execute. I'll do. Otherwise, if you're writing code that is doing weird thing, and there's all sorts of limitations, that exist in terms of what you can do because the run times are also different. When we have a real server, we have any run time that we want. We have any c libraries that we want. We have any language that we want. And a lot of the modern, edge compute locations or edge compute run times because they're also designed to run very, very fast on and not in necessarily, I'll say in air quotes, real service like, real they're not actually real servers. They are like a subset of the resources that a that these compute platforms have. So so, again, a couple of the popular ones I mentioned, CloudFlare and and CloudFront. Cloudfront is fronted by, Lambders, but not real Lambders. They're actually a subset of the Lambda runtime, that can only run certain limited amount of JavaScript. What? In an effort to be less computationally expensive? That, but also they've developed from this need of okay. I just need to transform an image very slightly. And over time, we've just kind of put trying to put more and more things in it. Cloudflare is is is a bit more is a lot more advanced. And also the CloudFront one, since I've used it back then, it has got a lot more complicated as well and has gained a lot more features. CloudFront have again, it's a limited runtime. It's not node. It is a node compatible runtime, but you don't have access to say every single node library or you don't have access maybe even to the entire node modules, or the entire NPM registry. Oh, is this, is this isolates where it's like pure it's a pure JavaScript runtime with, like, some exposed additional functionality? Because we use those inside of directors, inside of our automation builder. But I didn't know that a lot of the JavaScript creature comforts, things even like console log, things like set time out and things like this, they're not they're not part of Node JS. They're not part of, sorry, the core JavaScript spec. They're part of Node and the browser implementation of JavaScript. And you take for granted when these are the 2 really predominant runtimes that we use. So maybe it's something like that where they're using these isolate, environments with whatever additional functionality is exposed by the vendor. Yep. Yep. I I think isolates her was inspired by some of the some of the work that cloud flooded or or may even be a direct, a direct thing from from from Cloudflare. Yeah. Is it a direct descendant? But, but, yeah, it's it's exactly that of of we're no longer in the browser. We're very much on a highly efficient, sub resource, that exists far out on on the edges of of these compute regions. And if we if we were to bring up a map, and I'll share share some assets after as well of we we know the general, you know, EU west 2 being London and, US east 2 from AWS being, you know, in Ohio somewhere and your EU West 1 or your or Google's, you know, EU Central 1 in Norway. These are all locations that they have massive, massive, huge data centers with further sub availability zones being, you know, eu west 1ab, e u west 1 c, etcetera. So huge, huge, you know, warehouse sized data centers with tons and tons of servers that have tons and tons of services on them. When you additionally look at the map of of, what are the cloud front regions, which are regions where AWS or some other, you know Vendor. Vendor may have, caching locations for, which which are much the smallest subset of machines that they that they control that in partner data centers or in what are called crosslink or interlinked locations where, you know, many vendors, have their servers and, you know, pass cables all over to each other. That's sort of how how the Internet works in that. There's a whole bunch of data centers where eventually cables interlink with each other's data centers. But vendors will have also service in these locations, and these locations are, you know, a lot pricier, a lot closer to the user, and also run much less much much more controlled environments. And these are these are these are what we actually refer to. This is what we really, really refer to when we talk about edge locations. We can be close to the user in terms of real locations also in terms of okay. Practically, you sort of want say, if you have a server in you e in US in the West Coast of the US in California, you would also really like a u a a server sort of in Europe ish to serve most of Europe. And then the next optimization is to put them super, super, super close to exactly where, you know, their ISP will interlink and hop over into AWS's domain. And that that right there is where we where we actually talk about edge compute. Interesting. So we're putting them beyond server farms going all the way down to kind of the interchanges. And that's all, yeah, we kind of we we put up with lesser resource at our disposal, because also we're sharing with a lot more users or, like, the servers have to serve, you know, many other users, things like that. And, also, because we're so close to the edge and we're doing many other things like fetching and, you know, sending things over the wire as we're streaming. We're we're we're constrained to much more, much faster response times. So Cloudflow, for example, I think you you have to do whatever you whatever compute you do on that edge has to be within, like, half half a second or something or or a second, and you can't do anything more than that, and you get instantly cut off. That's fascinating. So this is really interesting because I thought edge computing was a concept that anyone could apply. It's just the idea that, hey. You know what? I'm gonna spin up resources on these different, you know, servers and do some complex, you know, routing of those. No. It really is provided by vendors who are kind of more at that backbone layer of infrastructure. And it's uniquely enabled by being really close to what you're calling these interchanges. That's really interesting and not something I quite understood because it's never a marketing material because it's it's really getting in the weeds. Yep. Edge computing, unfortunately, is a very monopolistic type, very, type of operation because it's not anything that we can get involved with. I I cannot I cannot go and run around and just give people, just put some pies around in server files. Just that. Also, nice sticker. That is a retro sticker. Of mine. Yeah. Because there's there's even more stickers in Slack. I can't afford to go and put these servers around, really, really close to users because I do not own that infrastructure, and I would never have access to that infrastructure because you need a lot a lot of money to be put into these type of locations. Like, you need to be running a network. But what you were describing there for just a moment as well of, yeah, just being able to put services kind of vaguely close to users, that is distributed computing, which is different from edge computing. It's both that's an versions of distributed computing are also very important to our goals of of, serving content to users really, really quickly. And this should be a computing and edge computing kind of go a little bit hand in hand as well. Because in in this day and age, at least today, we do have, and you raised at at the head of the show as well, your talk about databases or or data as well. This day and age, we sort of have, an inkling of kind of like the early CDN days. We have an inkling of being able to put databases on the edge. But, again, because there's such limited sub resourced run times, it's very, very difficult. So the current generation of databases still lie on the distributed computing layer, which means we our our content can be really, really close to the user. And, hopefully, the content that that little edge computing box is requesting is is kind of like our users are over here, and then the the users of our database being the edge computing nodes, we wanna also be close to those users. So, we need to we need to both balance, where we put the user's content and also where you put the edge computing nodes content. Yeah. Yeah. And more often than that, you know, at the end of the day, a website is kind of putting together a whole bunch of database queries. Right? Most websites. So if if we can also put the data that is needed to construct that web page close to where it is being constructed, then we have further performance gain. If we can get it if we can get them collocated right next to each other, that's fantastic. And one of the arguments against edge computing always like and you've also mentioned it as well. Why go through all the hassle to need to have this, now we have less environment. Now we have we can't use all my nice libraries, and I have to I have to struggle with, you know, doing things in under 500 milliseconds and whatever. Why do I have to go through all these struggles when it's good enough if they can just access my already distributed you know, I've already put a node in Europe, and I've already put a node in the US. That's good enough. And it comes down to what is the quality that what is the quality experience that we are aiming for? Are we aiming for near native, or, is, you know, is good enough good enough? I am a firm believer in it's the world wide web, and it's not the US web. And there was a time, Guillermo Rauch, kind of pioneers a little bit now with with Vercel, and their efforts in in edge compute or or delivering good UX as well to developers for for engineering on these new new run times. I've read the tweet of him once of in the early days when he was setting up Vercel or, whatever it was called back in the day. Zite. Zite. Zite.zite.co. Whenever he's setting up zite.co and he first went to the s went first went to San Francisco, he's like, oh my god. The Internet's so fast over here because that's just where that's just where your your data center starts is in the US. And then good luck when you finally if you decide to put a server somewhere in Europe and we get access to some slightly faster websites. And And at the end of the day, we are talking slightly faster here and there in a lot of cases because our undersea cables between, you know, Europe and the US are pretty fast. If I was to put a data center in Oregon, and we can do we can do this this is one thing we can do. We could do a little, ping test as these sites that can ping across all the data centers. If you if if you do a ping test into Ohio, it's about 250 to 300 milliseconds of round trip time. Vaguely okay for most for most use cases. It depend it depends how resource intensive your application is, I suppose. If you're starting to build something that's really, really bandwidth intensive, multimedia site, actually, it starts to matter a lot more. Yep. Multimedia if just even just a normal website. That's that's that's kind of fine for Europe. Right? But, again, we're not the worldwide web of US and UK. We're the world wide web. And imagine having being in Australia or being in South Africa or being in India or being in China, and having 800 milliseconds to 1.2 seconds of round trip time. And that is round trip time meaning on literally anything that you do. So first, there's and in modern web applications, that is alright. First load HTML. 1.2 seconds just to get the first request going with streaming HTML, then it hits some JavaScript that he has to go fetch. And that's another 1.2 seconds of doing that. And that's that's just the round trip time, not only you then have to be downloading through that entire time. So it's it really compounds the more that's going on. And when we're aiming for native like snappiness, the goal the goal is native like snappiness with edge. And if the the the point is we need to get things really, really close to the user for that initial load. Humans, there's a psychological, element to slowness or to to delivering fast experiences. And if we can show things quickly, it doesn't matter as much how long it actually takes to then deliver things as long as something's happening. There's actually an interesting UX that exists today in AI because, there's this new UX pattern now of streaming text Oh, yeah. Which we didn't have a year ago. The the data physically doesn't exist when that when I start getting a response. It's yeah. And you you you imagine if if if we didn't have that u that UX only serves the purpose of AI being too slow today. Imagine us having to wait a full 10 seconds for us to get the full kind of page back of the AI response. That it that that would be an extremely frustrating human UX experience. But just by the fact that it's actually coming in character by character, you think, oh, shit. That was really fast. Because you you actually you're reading you and you're consuming. And that is the UX that edge computing is trying to tackle of. And having having a risk response back instantly and having your content just there straight away. Could I ask a question? When you were talking about the, the concern I had around the effort that needs to go in, the effort you described was all about writing performant code in a more, in a more limited environment. But I ask, what is the actual work involved in setting up edge applications beyond just writing code that will run? Do I have to manage where stuff is, or do I basically just, like, fling it up to a vendor and they take care of the of the distribution of that? Like, is there is there work required to physically make it edge code that will run on the edge beyond the environment and beyond the, the performance requirements? There is a gradient. There there there is there is a gradient of of effort that can be spent here. And every sing every single day, there are new there is more and more tooling that makes it easier. As a baseline, anything you do in AWS will be hard because they are a platform. Right? They're they're just they they are they are infrastructure of a service. They're not the platform, and they're not the tooling. They are they have other services on top, like, you know, your, whatever they call their their stuff. Amp Amplify. Amplify. AWS Amplify are sort of some of those toolings that do distribute compute. Google Cloud, also, it's gonna be hard, but they have other services built on top. They have things like Cloud Spanner is their distributed database. Really, really fun if you read their white paper on on Cloud Spanner. It's it's a very googly white paper, and it's very very overcomplicated thing. And they talk about syncing satellites and time clocks in servers across the planet and how they use this network of satellites to have, like, microsecond time precision is very interesting read. Highly recommend. There's things like that. And there's Firebase on top, which also does distributed computing. And so there's, so there's frameworks built upon these things that that that make it easier. And ultimately, it comes down to it to frameworks or other platforms that make it easier as we go up the stack. Vercel also are a platform, but they make underneath you know, they they use AWS Lambdas. They use Cloudflare edge workers. Mhmm. And that's sort of where if if you've ever experienced working with Nest, which is, again, kind of another superset on top of Vercel, because it just kinda uses all of Vercel features. When you are working in a an edge nest route, you have a limited amount you have a subset of things that you are able to sort of do from from the from the platform Sure. Because it's running it's no longer running on a Lambda, which is a 4 Node JS instance. It's actually running on a Cloudflare Worker, which is that isolate that you just described. So they are tooling. There is tooling that makes it easier. And then in other realms, in databases or in CDNs, there's more tooling there as well. There's there there's such tools like, PlanetScale is becoming very popular these days with its easy distributed computing of or easy distributed computing of databases. And there are other things that are trying to actually put databases on the edge, and the current kind of front runner for that are, SQLite, which actually Cloudflare again, another pioneer in this area. KV, key value store, is a product that is built on SQLite. Dino, have a KV, a key value store. Again, kind of built not on SQLite directly, but a fork of it that does this distributed computing. A whole bunch of startups doing SQLite type distributed databases. Edge actually, edge database. Not only distributed, but actual edge On those edge nodes. The how does syncing oh, sorry. What I'm basically hearing is vendors more or less will take care of the of the distributing of your assets, whatever those assets are across nodes that they make available. That's not something I necessarily need to do. If I don't care about edge, if I just care about distributed, it's something I could do with great pain. Yep. I or I imagine there's tooling still. But a lot of these vendors will just take care of that. That's part of the offering. What about syncing stuff? Surely, there's some trade off around, you know, even if it's the data store is what I'll call it over a database. The data store, the cloud, you know, the cloud functions that run the edge functions, and all the assets and stuff like that. How do they all stay in sync? Obviously, when I push an explicit update, I imagine there is an explicit, you know, propagation of that of the updates. But just day to day, I Mhmm. I'm a user. I add an item to a data store that happens near me. How does it get to everything else? And is there a risk involved that things will start to fall out of sync? Yep. Certainly. Now the for the KV stores, for the for the SQLite stores, I've really not read up enough about what's going on there. It's like mind blowing stuff that goes beyond my comprehension right now. So I have no idea how they sync because, also, SQLite is a binary data format. So it's it's mostly if anything, I believe it's kind of for, like, edge caching or some sort of be able to write small things. I don't I don't know how it gets back to your main server. Crazy crazy black magic over there. Sorry. Can I pause you? Your main server. So, in all of this, there's still a main server running that You could. You could. Or at least, you you you definitely could write you kind of have to flip how you how you develop. If you wanna be entirely edge, you certainly can. And a lot of use cases don't really fit into just being entirely edge. Mhmm. Even with, say, Vercel, for all their efforts in doing, distributed computing, or edge computing, when you actually log into your Vercel instance, there is a drop down that you could actually pick your main location that it that it puts. Interesting. It's, it still needs to run that Lambda somewhere in some AWS data center. So there's still a a a main place that you're actually doing real compute. You can definitely, if put with a lot of effort, build entirely edge, services, but there will be points at which you need to escape from that to build, to have the full, you know, a company of of real runtime. Sure. And any other any other service that you might need to inter interconnect with, like any, like, queuing system or whatever or and any any real app that is doing something more complicated than just serving a website is gonna need other resource that cannot be run on the edge. And, honestly, it doesn't necessarily even need to run on the edge because we can get you know, there there is, like, the liveness of the website and your interactivity. And then there may be other things that you need to do in terms of, you know, workers or sending batch emails or, you know, do doing other compute or, like, you know, on YouTube scale, like, you know, upload a video and you have to transcode it and all that. So there there there's there's always other things that you may need to do in a in a business to serve whatever use case that your business is serving, but the the, serving of a website can kinda be isolated down to, you know, this edge thing. That's but that's fascinating. I never thought about that. Edge is like a is like one of the tools in a wider application. It's not I it's not application that's very traditional or perhaps distributed or whatever, but it runs properly. And then elements of this application are run on the edge that benefit from the, from the characteristics of running on the edge. That is something that has never quite I never knew that. That's really interesting. But is it fair to say that that core application has to coordinate the edge nodes? Is that what you're what you're thinking? Because you said because you were talking about stuff going back to your main application. Tangent. You you you you could. And I and I think it's it's really clicking with you when, earlier when I was describing, you know, just delivering full page versus those small elements of it, and it's like and it's kind of exactly that. But in terms of coordination, you know, this this then gets into, you know, microservice distributed computing type deals of, like, okay. They they can be isolated in their own way and, more was more referring to when sending things back is kind of the data that the user may may have input. So user input or, you know, if they're chatting away, if they're interacting with if they purchased a ticket and writing that back to the source of truth that ultimately, there must be a source of truth somewhere. Ultimately, some database needs to know that, look, the tickets were a 100, and now they're 99 available. Someone needs to know and be written back to, and that's what I what I'm referring to when I say, okay. Eventually, get back to Got it. That that source. Got it. Got it. And there's many strategies that we can employ on that source of truth because we can we can have a distributed source of truth. Kinda this Cloud Spanner database from Google, which kinda came out, like, 8 years ago, and that that white paper was making its rounds in distributed computing land, was really, really exciting because it sold it was trying to solve the problem of multi node writers. It's a challenging databases today to have multiple, multiple writer nodes. So current current database technology relies on having a single writer with multiple read rep. So you can you can you can replicate readers all day long because it's easy to, and sort of the the whole theme of this conversation has been it's really easy to replicate, caching content, so replicate reading content, but it's very, very hard to replicate writing or updating content or Absolutely. Invalidating. So it's always been very easy to do low latency writes with low latency read replicas where, you know, you might have, you know, those, you know, basic basically, the the ping between 2 servers be your latency from from read write replicas. So you may say and it and depending on your use cases, it may be acceptable that, okay, Europe is, say, 500 milliseconds behind US. So if you were to go to a website, technically, you would be seeing 500 millisecond, stale content, and that may be acceptable. But it may in terms of fairness of the Internet or the World Wide Web and not the UK, US Web, It's unfair to set to always put an advantage on, your your geological, position. So, technically, or, and I think that there there was an article once upon a time around when the Cloudspana or one of the Cloudspana customers originally was Ticketmaster. And their particular use case was this sort of fairness topic of well, okay. Australia will always be 1.2 seconds behind everybody. So if they go to book a ticket and someone literally just, you know, 1.2 seconds closer to the server clicks it, they will always win. So it's unfair to put people at this kind of dispute disadvantage. So we're trying to build technologies that distribute these rights more evenly, and you can get kind of more fair distribution of of updates. Yes. Ticketmaster, the bastion of fairness. Sorry. Please continue. Well, in in in reality, what they actually want is, you know, more they can cash less and not have this this, queuing system, which which leads to more clicks, more purchases. Right? That's that's that's the end goal. That's the end goal with all of this. There's well documented stats about how Google goes about about web performance on the web. And, you know, if you're x milliseconds slower than a competitor, you know, you're more likely to drop off and just go to the next site that is faster. So while us as engineers, we wanna over complicate our life and do fun complicated engineering things, Us as business people, we wanna deliver things fast because it yields greater returns and is a better native experience and will yield happier users. That's ultimately the goal that we're trying to trying to solve, while also doing it more cheaply, hopefully. Or at least over time. So a question for you then. In the current state of edge computing, what are people actually doing on the edge beyond what, you know, what was once possible with, you know, just CDNs? What people what the most trendy thing now is we are rendering HTML on the edge. We are rendering websites closer to users. And what I mean by rendering websites is we are rendering more interactive content next to the user. So no longer are we constructing the whole webs web page, you know, 800 milliseconds away from the user and then delivering that over the wire. We are constructing it closer, meaning all the other subsequent calls that we might have to make to other services, are hopefully also calling services also closer to that edge region. So it's it's more and more, companies are putting more and more of their own services in more locations. Sure. So say, let's take an example of I wanna construct a web pay a Shopify web page. Shopify have a fantastic global API network. I argue that actually Shopify have the most distributed database on the market because actually, you know, when you update something in Shopify, it's already distributed to their network of of of re replicas around the world. If I was to construct the data there, and then, okay, I also call out to another service that I control, or I also call out to, like, another partner API. If we if we request that, make a request there, and it goes 800 milliseconds to wherever it was being constructed, and then that that does its course and it comes 800 milliseconds back, that's, you know, 600 a 1.6 second round trip or whatever. If we take that request and say put it right next to the user and go, okay. As soon as it comes in, I'm instantly streaming back. So it's close to the user, say, 20 milliseconds away. Generally, edge location is a sub 100 millisecond close to the user. Good to know. So they they hit it. Instantly, they get back, you know, they white page with loading things, and it goes, okay. Slows this. Okay. Now I need to grab some stuff from Shopify. I've done a request to Shopify back and forth. Hopefully, they're also at edge location, 20 milliseconds back and forth on my edge. I've got my Shopify content. Oh, I'm doing an AB test. I've hit my AB test service.com, and I've got back the result of what needs to happen. And, okay, I've loaded that content. And it's this it's this dynamicness that we wanna put closer and closer to the user because if we were to And it and it compounds. Yep. All of these 800 millisecond round trips are grueling, but a bunch of 20. I mean, of course, you still wanna be mindful of how many you're doing, but that's the same in any web application. But we're talking orders of magnitude quicker realistically when you're loading any modern web application. Exactly. Yep. So it's it's it's more it's more of this dynamicness because we could totally just off cache that entire page and delivered it to all the users equally. But what if one one user is logged in, one user has a basket where they, that that that we wanna also display and and render on the server? We could totally render it on the client, and this is where also this new modern trend of, you know, it was very it was perfectly fine to deliver entire huge bundle to the user and it be interactive and do API calls on the client side because the client side is also an edge location. Sure. But we pay for the upfront cost of them receiving that bundle. So if we can That's interesting. Yep. So it's that trade off still of speed. We need to deliver a a reasonable experience as quickly as possible. Then, ideally, we want all subsequent requests to be as speedy as possible. But if, you know, if this is where we're starting to pay a little bit, that can be more acceptable dependent on user and kind of, developer experience or, like, you know, vendor experience requirements. Exactly. That's really interesting. So it's just this trade off of of requirements. I feel like this, you know, edge computing starting to gain some traction is bringing a whole new realm of, I don't know what to call that requirement gathering, like, trade off decisions for developers who didn't need to care as much about infrastructure before. And now suddenly, the same way front end developers now have to do a bunch of back end work with these kind of mixed hybrid frameworks that run everywhere. I feel like in the in the same way, anyone who does back end work is now having to care about infrastructure in a way where perhaps the the expectations in the past were less than. Yep. And then it's the job of these vendors who who run edge nodes to make that experience as contain as little pain as possible. I think I think you've hit the nail right right on the head there is, we we've we've this this trend is the flip side of is is the next evolution of SPAs, of single page web apps. So that was our edge in the past, and that was our limps limited subset runtime. We could only run JavaScript, then we could only run web JavaScript in that runtime. And, what we're having now is that it's a limited run time, yes, but there's we have more languages, more things that we can run closer to the user, and it's we're delivering them. We're not using the user's resource. Right? So a a lot of SPAs or a lot of, mid 2000 in the Internet relied on, you know, fast devices or, you know, doing a lot of read writing of, you know, the DOM tree and all this, and then lower, lower quality devices with less CPU, like dumb phones or or or or basic Android devices had, you know, a worse experience on the web. And what we're trying to deliver is by doing doing the complexities of the HTML rendering and whatnot close to the user and delivering them, you know, the content that just needs to be rendered and device can become dumber again, and need to do less, you know, JavaScript execution on the client. Because, really, all we all we actually want at the end of the day is to deliver that HTML to the user. And that liveness, that interactivity used to come from or used to only be able to come from SPAs, client side JavaScript. And what we're seeing today is that we're moving more and more of that client JavaScript onto the server, but also quite close to the user to be kind of that native like experience. And that and they're the parts they're the parts. It is we want to make the users do as little computation as possible while not, suffering based on their location. The fact that a load of that computation is going to happen elsewhere. And it's that specific pairing of of requirements, that makes edge com that makes distributed computing more powerful and even more so edge computing because they run right at those interchanges. That's that's great. Now, for some of the other episodes of, learning things I love to hate, we went into a demo, but I feel like we've covered a lot here. I don't necessarily think we need to we need to do it so much. Plus, it's a really abstract concept where, you know, I'm sure there are ways, but it isn't gonna be now it's running on the edge, and we can really show that to its fullest. But I think I understand a little more why why edge computing is interesting now. Some more or less basic concepts about how it works when it also might not always be right. And this new idea that, oh, no. It's just parts of your application you can delegate to the edge. Again, not something that is spoken about by the hype machine very often. Yep. It's just edge edge edge edge all the time. Just parts. Just parts. Right? And we we we have the we have the same mistaken view of serverless computing, in the past where it was like, okay. Now everything must be serverless. Mhmm. No. It's a subset of use cases that are that that benefit from it, and that's the it's the same with the edge. It's not we don't wanna put we don't need to put the entire server close to the user. That's impractical. But elements of it definitely can. And, and, yeah, and I think the the the the the reason it's so abstract in this way is it's hard for us to experience what other people are experiencing when we're in our, you know, our our nice modern MacBook on gigabit Internet in countries with good Internet. So it's it's hard to put us put ourselves in those shoes. And, the way we used to do that with SPAs and stuff is literally have a crappy old Android phone for dev that you would, you know, every so often look at and use. And we can replicate that if try try the web on a, on a VPN every so often. Or if you're in a foreign country, try going to some of your favorite websites and just seeing how much slower they might feel. Because, yeah, it's it's conjured up a memory of a it's slightly off topic, but you've just conjured up a memory of in London, Mozilla used to have an open community space, and in that, they had what they called the Mozilla Device Lab. I imagine there were a few of them, and it was just a bunch of different devices. Or, like, they run they run browsers which are, you know, really, really, really limited with this exact idea that you could be testing on all these different devices. But, yeah, now we need to consider and I suppose that's the other part here. What edge computing enables is less computation happening on a user device, so it's lowering the needs on the user device, and it is making that computation closer. So we're kinda leveling the playing field. It's this fairness, as you mentioned earlier, of you don't need the best hardware, and it doesn't necessarily matter where in the world you are. Both of those factors are handled by this new emergent technology. Exactly. Exactly. And it's it's it's all it's all right as rain for us to talk about fairness, but at the end of the day is we want to have users around the world because we're hitting we're hitting more ability for us to sell to more users. And at the end of the day, that's really what we're trying to solve with with edge computing because get more and more users with more and more happy users because we can have users that are unhappy, but, really, we wanna have more and more happy users. Yeah. Awesome. Thank you so much for joining me. This has been really, really interesting. I'm loving filming this series. I'm learning tons. And hopefully people who have joined us for the ride also, are learning loads. Just before we go, is there anything else you wanna share, point people to where to find you? Sure. I mean, if you want if you wanna see more of, like, crazy drawings on my Twitter, I'm I'm at Pandeliszed, p a n d e l I s, zed, on Twitter. It's it's funny when I was drawing that in the office because we we kinda sit in a bit of a semicircle, and my colleagues turned around and were like, what? How are you doing? I'm like, oh, just drawing. Just drawing some stick figures. I was like, okay. Fine. But, yep, that's that's that's where my normal antics are or on Twitter. And, and yeah. No. I'm so so happy, that you had me, Kevin, and it was, I I saw your brain clicking at the end there. So I'm so glad that I could I could share that with you, and, hopefully, it's it's no longer anything that you that you hate. It is not something that I hate. I have, a newfound like other episodes, a newfound appreciation and more importantly, an understanding of the qualities. Right? Which mean that it may be something I reach for when appropriate. Whereas before, I just lacked the knowledge. So I was never gonna reach for it. And, you know, in time, that could lead to me building things that aren't as good, as they could be. So, yeah, thank you ever so much. Thank you to everyone who has joined us, and, we will see you in another episode of learning things I love to hate. Bye.",[201,202],"57414d28-d5db-4707-b406-13defc07b9e7","7cff1776-681e-4853-9afa-7feae1415ddb",[],{"reps":205},[206,262],{"name":207,"sdr":8,"link":208,"countries":209,"states":211},"John Daniels","https://meet.directus.io/meetings/john2144/john-contact-form-meeting",[210],"United States",[212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261],"Michigan","Indiana","Ohio","West Virginia","Kentucky","Virginia","Tennessee","North Carolina","South Carolina","Georgia","Florida","Alabama","Mississippi","New York","MI","IN","OH","WV","KY","VA","TN","NC","SC","GA","FL","AL","MS","NY","Connecticut","CT","Delaware","DE","Maine","ME","Maryland","MD","Massachusetts","MA","New Hampshire","NH","New Jersey","NJ","Pennsylvania","PA","Rhode Island","RI","Vermont","VT","Washington DC","DC",{"name":263,"link":264,"countries":265},"Michelle Riber","https://meetings.hubspot.com/mriber",[266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,243,454,455],"Albania","ALB","Algeria","DZA","Andorra","AND","Angola","AGO","Austria","AUT","Belgium","BEL","Benin","BEN","Bosnia and Herzegovina","BIH","Botswana","BWA","Bulgaria","BGR","Burkina Faso","BFA","Burundi","BDI","Cameroon","CMR","Cape Verde","CPV","Central African Republic","CAF","Chad","TCD","Comoros","COM","Côte d'Ivoire","CIV","Croatia","HRV","Czech Republic","CZE","Democratic Republic of Congo","COD","Denmark","DNK","Djibouti","DJI","Egypt","EGY","Equatorial Guinea","GNQ","Eritrea","ERI","Estonia","EST","Eswatini","SWZ","Ethiopia","ETH","Finland","FIN","France","FRA","Gabon","GAB","Gambia","GMB","Ghana","GHA","Greece","GRC","Guinea","GIN","Guinea-Bissau","GNB","Hungary","HUN","Iceland","ISL","Ireland","IRL","Italy","ITA","Kenya","KEN","Latvia","LVA","Lesotho","LSO","Liberia","LBR","Libya","LBY","Liechtenstein","LIE","Lithuania","LTU","Luxembourg","LUX","Madagascar","MDG","Malawi","MWI","Mali","MLI","Malta","MLT","Mauritania","MRT","Mauritius","MUS","Moldova","MDA","Monaco","MCO","Montenegro","MNE","Morocco","MAR","Mozambique","MOZ","Namibia","NAM","Niger","NER","Nigeria","NGA","North Macedonia","MKD","Norway","NOR","Poland","POL","Portugal","PRT","Republic of Congo","COG","Romania","ROU","Rwanda","RWA","San Marino","SMR","São Tomé and Príncipe","STP","Senegal","SEN","Serbia","SRB","Seychelles","SYC","Sierra Leone","SLE","Slovakia","SVK","Slovenia","SVN","Somalia","SOM","South Africa","ZAF","South Sudan","SSD","Spain","ESP","Sudan","SDN","Sweden","SWE","Tanzania","TZA","Togo","TGO","Tunisia","TUN","Uganda","UGA","United Kingdom","GBR","Vatican City","VAT","Zambia","ZMB","Zimbabwe","ZWE","UK","Germany","Netherlands","Switzerland","CH","NL",1773850419705]