To the Edge and back again
Alright. Dax, what is the edge? Can you tell me, No.
Dax:No prepper. Like,
Adam:no pull up.
Dax:Just straight to go.
Adam:What is the edge?
Dax:The the edge is something everyone's talking about. People can't get enough of the edge. Everything has
Adam:to edge. But what is it? Does anyone do it actually?
Dax:I don't I don't know if anyone's really doing it. So and more seriously, so I I did a I did a video on this topic just because it was, like, coming up so much and people asked about it so much.
Adam:I feel bad that I haven't seen it. Is this been up for a while, or have you not published it?
Dax:No. I have. I mean, it wasn't anything crazy. Okay. But, yeah, I think it comes up a lot because there's always like, you know, the hype cycle always happens with everything.
Dax:There's a new concept. It's it's genuinely exciting. There's, like, genuinely really interesting things about it. But because it's exciting, it gets talked about a lot, and then it blows up. People feel like everything is gonna be on this new thing.
Dax:Everything has to switch to it. It's a future if you don't have it. If you're not doing it, you're over.
Adam:I feel that way.
Dax:Yeah. I've gone through this process so many times. And when a new thing comes, still it just still sucks you in. It's really hard Yeah. To, like, look at something objectively.
Dax:And then eventually, at some point, it goes the other way where people are like, this sucks. This is terrible. Like, we've all been lied to.
Adam:I've seen that curve. Back up like a weird place. That's just the hype cycle curve. I've definitely seen that where it's like, it peaks and then crashes way low and then slowly. So it will eventually be relevant and we're just not there yet.
Dax:I feel like I've just seen this happen so many times with literally every single thing that I'm like, it just has to happen again. Like, this is what we do Yeah. As an industry.
Adam:So So is the tech not there yet? Because like, I know Next. Js Conf, they're getting ready to talk about the edge, like nonstop for a whole day from what I've gathered from tweets. It just
Dax:I not don't there think it's I think it's more like with like with every single thing in engineering, there's always trade offs. And if you make one thing better, you're making another thing worse. The edge isn't magic. It's all is subject to distributed systems rules. If you move stuff, if you move some things closer to your users, now those things are further away from some of your other stuff.
Dax:So you're paying the price somewhere else.
Adam:Is this the cap theorem? Sorry, just keep it.
Dax:Yeah, exactly. Exactly. The cap theorem still applies like you still have to deal with all those issues. And I think a lot these services have done a good job moving your front end to the edge, which makes a lot of sense. Like, that's like the least computationally heavy, state heavy thing in your whole architecture.
Dax:Just like
Adam:the files sitting on a CDN, like, that's they're at the edge. You get them quickly, but then all your API calls and things like that are slow because they're
Dax:not Yeah. They they still go to a region, like a centralized region, and maybe you have multiple regions, whatever it is. You know, that, you know, it's pretty good for certain architectures. But now we have, like, computing at the edge where you're moving your business logic to the edge. And that feels great because, like, oh, the user is right there.
Dax:The business logic is right there. It's gonna be instant. But then it's it's kind of like, okay, but your business logic still needs to write things to a database. Right. Which is probably still in a regional zone.
Dax:So now every round trip is more expensive. This all actually worth it? Might actually be slower.
Adam:Your compute and your database are now separated geographically, and that's slow.
Dax:Yeah. You just
Adam:put everything on the edge? I know people talk about like SQLite. Can you just put SQLite databases everywhere on the edge? How does that work? How do they all stay in sync?
Dax:Well, so that's that's the next problem. You okay. So now let's move the database to the edge. Now it feels like we solved it, but now your database is further away from other database nodes than it used to be. Yeah.
Dax:There's a whole new suite of problems there. And all that SQLite stuff is really interesting. Like, they're good options. I feel like all of the cloud has just been we optimize for one use case, then we flip the decisions, and now you have a different set of things you optimize for. Then you flip it and you have a different set of things you optimize for.
Dax:So SQLite stuff, pretty interesting, like reads at the edge that are eventually consistent, all your rights will go to a single place. I think for some stuff that could be cool. Do I think every single thing is gonna move to that? No. I think my proof is, I mean, I have a question for you.
Dax:Like how often do you even see companies operating in multiple regions? Yeah, no. It's like I rarely ever Yeah. See So if people haven't, the option of operating in multiple regions has been possible forever. Very few companies opt to do that because it's comes with trade offs, difficulty, etcetera.
Dax:So if you haven't even done multiple regions, doing edge is like doing a thousand regions. Right?
Adam:So Yeah.
Dax:So Yeah. It it's challenging.
Adam:So, like, if you think about Vercel and Next. Js Conf, they're gonna be talking a lot about because you can basically do you're you're not you're not a Next. Js user. I forget. But you can run, like, your API routes in NextJS or your SSR at the edge now.
Adam:I know that was, a recent thing. But, like, is is it just are they just glossing over? Does anyone talk about what you do with your data store? I've never heard Vercel talk about that, but have I just missed it?
Dax:No. I I honestly don't know either. And we see a lot of people so I think the edge stuff is great. You can move more like, you're back into your edge, But people end up moving their whole back into the edge, so they don't have like an API anymore that's regional. Yeah.
Dax:And then stuff starts to be slow. Like the round trips, like it's at the database are slow. I am the ideal setup, which is probably too extreme for most companies, but the ideal setup is your Next. Js Next. Js Next.
Dax:Js app deployed to the edge. But the back but it's not talking to your database. It's talking to a regional API, your GraphQL API, whatever, AppSync API, whatever it is, and then that talks to your database. That way your edge to regional can still be a single round trip because GraphQL, you can kind of like batch everything you need into a single request. Then you can do as many round trips with the database as you want because your regional API is close to it.
Dax:Yeah. Get the response back. I think that's like the ideal setup. I think people right now are perceiving it as, oh, I don't need that
Adam:regional API. So the regional API just lives like in US East 1 or something if you're dumb. Yeah. Everyone else regions, whatever. Yeah.
Adam:So if in that scenario, your Next. Js API route is maybe hitting from, like, Central Europe, it's going across and hitting The US data center. So that's the slow part. But how does that manifest? I'm just trying to think through that's the other thing I started thinking about is, like, on the right side, like, on mutations in a GraphQL sense, how much does it even matter?
Adam:How much does performance like, I started getting really into nerding out on this stuff, and then it's like, if you just optimistically, like, update your UI, does any of it matter?
Dax:I don't think it does. My whole thing with this is we have tools to capture certain metrics, like all the Lighthouse scores, that captures like a set of metrics and everyone knows them, so we can optimize for those. But we don't have tools to measure other stuff. Like when someone uses an app, does it feel fast? Like you can't pull every user and like, how does this feel?
Dax:I found that most of the answer to does that feel fast? Doesn't come from these architectural things. It comes from what you're talking about, little tricks that you do, and the app to lie to the user and make it seem like something happened instantly when it didn't. That's where you get the snapping feeling apps from, like things like linear, superhuman, like things like that. It doesn't really come from this stuff.
Dax:Like, all of those systems are they're not like these crazy edge rendered things. They're, like, pretty they're, like, s p old school SPAs. I'm saying old school now because of kind of SPAs.
Adam:We've we've bent away from that. And that that's another thing I just wanna talk to you about. And I don't know. We'll get into something AWS at some point, I'm sure. But the whole, like, MPA, SPA, the whole dialogue around web right now, honestly, it confuses me.
Adam:I don't even I feel like I don't know enough to even engage in that conversation. I see really smart people talking about it, and, like, I'll literally read their tweets, like, really smart people. I'll read them, and I just can't even comprehend what they're saying. Do you understand that whole debate and, like, where things are going? Because I just don't get
Dax:Very little. I I definitely understand what these options are. But, like, within the options that, like, the user understands, there's, all these sub options. And I think it's mostly framework authors talking with each other on that, which makes sense. Like, we're never really gonna be able to keep up with that.
Dax:But I'm also confused because I work on like actual products, and I like try to make them fast, make them feel snappy. And there's things that I'm doing, and there's things that I care about. Then I look at the conversation about performance, and I'm like, I'm not doing any of those things. Is that bad? Am I like optimizing for this thing that's gonna be dead?
Dax:Like, I'm also like, you know, working like, work like, building stuff for developers. We wanna make sure we're aligned with where things are going. But, again, it's the same hype cycle. Right? It's I don't think it fully makes sense, but, you know, the energy around it's impossible to get sucked in.
Adam:And and what is the hype cycle on the whole MPA side? Like, is the hype cycle that things like streaming at the edge matter? I don't even know. I I literally just can't even follow the conversation. Like, is there is part of that on the hype cycle outside of the edge stuff?
Dax:Yeah. I definitely I definitely would say there's definitely I see conversations with, oh, you're using an SPA. That's bad. You need to be doing SSR. Everything needs to be SSR.
Dax:If it's not SSR, it has bad performance. Yeah. Computers are like a legacy way of doing things. If you see that, it's probably someone being tricked to use an SPA when they like, it's just like, you know, the the usual the usual things that you hear. But I think there's a lot of things that make sense as SSR.
Dax:I literally never I my whole career, I never worked. I generally don't work on stuff that's like public. I work on stuff that's like a b to b SaaS application. So it's for
Adam:a specific number of users and that's not the whole internet. And you don't need to worry about like, the initial payloads and all that stuff, like how big the bundles are or whatever.
Dax:Yeah, it's like something like use it for like hours at a time because it's like a productivity tool. So who cares about the initial load when it's like 0.001% of the whole session? Yeah. The joke I made about the obsession with SSR was everyone is optimizing for sites where people land, leave as fast as possible,
Adam:and never come back. Yeah. So that I think that's part of the problem. The thing that's so hard in in, like, all this debate and just thinking about new greenfield projects, I'm just always trying to build new stuff. I think part of it is just playing with different new stuff, stacks, and whatever.
Adam:But it's like, I can't I can't even understand the different types of things that get deployed to the web. And I know people talk about, like, apps versus sites, but it's way more complicated than that. Right? Like, do you have a good handle on that stuff? I'm just asking you random questions at this point.
Dax:It's just like it's none of this stuff is, like, breaks down in a clean categories. Like, even the app versus site thing, there's so we have so as I see, we have our docs page. Yeah. So sorry, docs site. So that's definitely like a site.
Dax:It's not an app you use. Yep. But even there, there's like client side client side routing versus server side routing. If it it could be a site that people for documentation, you might sit there and go to literally every single page and Yeah. And read everything.
Dax:So it makes sense to use client side routing. So things like feel fast when you navigate. But if people are landing there through Google and, like, reading one thing and leaving, you know, even then maybe you wanna use server side route or MPA, I guess it's called. Like, all these acronyms are are jumbled. So, yeah, it's it's it's just hard.
Dax:Like, I I think ultimately, none of these things matter.
Adam:Yeah. It doesn't matter. Yeah. I mean, it I go back to, the levels I owe, like, the Peter levels, like
Dax:Oh, yeah.
Adam:Single PHP page remote okay okay or whatever. Yeah. So It's like we all
Dax:care, We want to project that caring onto something. There's things that are out there that are like, okay, if you care, like do XYZ. So I think there's a lot out there that are saying, if you care, use this. So all you have to do is care. You'll find something.
Dax:If you care, like, you'll make it you'll make it work well.
Adam:So so what is your if it's not if edge is just part of the hype cycle right now and and doesn't matter that much maybe, and we're just all really excited. What is the thing that does matter a lot, you think, right now? Where what's something, like, in terms of performance and in terms of building apps for devs, like, today? Just general purpose. I know there's
Dax:so many different types of use cases, but is there something that's further along the hype cycle that's actually maturing that you're excited about? Yeah. I do think, like, event driven architecture is something I think past the hype cycle and lots of people using it in production, real companies, like, lots of new interesting things with that. And, yeah, I think, I mean, that's all my work is in that in that category
Adam:So and yours as well. Is that just the more is that, like, the better way to put serverless these days? Like, is that kind of like serverless was too, like, lumped in with too many things, and now we say event driven applications? Or is it like you can build a serverless app and not be event driven?
Dax:Yeah. I know I just know people hate the term serverless. I've I've I like it. I don't have
Adam:a problem with it. But it means a thing. I know what it kind of means.
Dax:Yeah, I get what people are talking about. Yeah. But I think it just has baggage. So now I say because when I say, you know, we're trying to make people use serverless, so like you should use serverless people. I don't know.
Dax:There's just some like projection that happens with it. So when I say event driven architecture, it's like, that's what I care about. I think event driven architecture allows for a lot of things to be serverless, so it's unlikely you'll be doing that and also not being serverless.
Adam:But it does like whenever I start talking about like so I asked on Twitter, like, why people avoid AWS, And a lot of people respond in the way I expect, which is they're used to, like, deploying their thing and putting it on a VPS or a VM or something, DigitalOcean droplet. And, like, AWS is more expensive or more confusing or whatever when I just need to do that. But I think, like, that's the fifteen years old way of doing app development. And but I hate using the term, like, monolith. I don't wanna be like, oh, you shouldn't build a monolith and deploy it on a VM.
Adam:It's more just like, you shouldn't have to deploy on a VM and think about VMs or OSs Yeah. Or any of that stuff. That's the thing that's important to me, but I hate using words like distributed and monolith, and I feel like that's not getting it the thing I care about. Does that make sense to you?
Dax:Yeah. I totally relate to that. I like monoliths cause I like understanding everything that's going on. I don't want, like, a million separate things that, you know I just never worked at a company of this scale where but under the scale, I mean, like, number of employees where that made sense. Yeah.
Dax:Same. I like monoliths. I just don't wanna have something running all the time. The thing I like about, the reason I've been using the phrase event driven architecture more is the idea I like is that your system doesn't exist unless it's processing some work.
Adam:Ah, okay. Yeah, I like that. I mean, that's the skills to zero kind of thing.
Dax:Yeah, exactly. Like unless there's a request that someone asks for, it's like your system design, there's nothing running, there's no VM running, you're not getting charged for that. It's not something that can like turn to a memory leak, whatever. It's a whole class of problems that go away. Yeah, it's tough because it's one of those things where it seems like minor.
Dax:Like, what's the difference between a VM always running and what I'm describing? There's just like a million downstream effects that once you start using it, you're like, oh, I don't have to deal with this anymore.
Adam:Or Yeah. Well, like, I've been in the world where you deploy apps to VMs and you have to think about those VMs and a disk fills up or something. Yeah. Something annoying like that, and that's the kind of stuff I never wanna think about again. And that's, I guess, the promise and what I love about building serverless apps.
Adam:But I guess I wanna go back to the monolith thing. It so event driven architectures, does does that not imply, like, it's not a monolith somehow? Like, I feel like those two terms are sort of, like, at conflict, I can't figure out why.
Dax:Yeah. I think, again, that's why I feel like we have to make up new terms for everything because everything just has baggage. When people I think historically, it was like, your application is a monolith, meaning it runs in one process. You should break it up into microservices, so it's not a monolith. And therefore, monolith meant not distributed and not monolith meant distributed.
Adam:Yeah.
Dax:But for me, think when I say here monolith, I just mean when you're writing code, when you're authoring code, it feels like one system you're working on. Yeah. You can easily touch all parts of the system. It's not this, like, broken up thing.
Adam:So it's like author time monolith, not necessarily, like, infrastructure monolith. Like, the way it's deployed is maybe very distributed or something, but that's like less the concern. It's more like author time concern.
Dax:Yeah. Exactly. And author time, like, especially for the first several several years of your company, you probably want a monolith. Yeah. The only and I would say even with a microservices route, I think I've only ever seen one company get microservices right, which is Cloudflare.
Dax:So they have a whole microservice system, even their functions as a Their functions platform is built on the concept of services, but they removed the distributed part from it entirely. They run every single service on every single machine. All the services just talk to each other within the same machine. So all the complexities of having a distributed system go away. So I think they're capturing the benefits of the isolation and compartmentalization without the overhead of it literally being a distributed system.
Dax:But, yeah, everywhere else, it's kind of like, you now have all these distributed systems problems. And I used to be, like I said, like, you know, I used to be a heavy Kubernetes user. So I'm not Yeah. Just hating on this stuff from, like, I'm on this team. I'm like, I used to be on that team.
Dax:And I remember remember all the skills that I was proud of having that looking back, I'm just like, I should just not have developed.
Adam:I'm on the other side. I mean, I've never messed with Kubernetes, but I'm still on the hating side, I guess. I that's a whole another conversation that I definitely wanna get into, like, the small team versus big team conversation. I think that's a a separate maybe conversation. But I definitely have thoughts about all that.
Adam:And this is all very, like it's very topical for me. I'm just trying to, like, communicate some of this stuff, and I feel like I run into the same walls in my brain when I try to explain, like, no. I think there's better ways today than we've done all these years. And it's just very hard to, like, communicate what that better way is and why I think it's a better way, but it is very much coming from
Dax:a context of small team or solo development. I just don't live outside of that. I gotta be honest, though. I feel like you don't I I feel the pressure to add that qualifier too, like, for small teams or for qualify for whatever. But to be honest, I don't really think that's necessarily true.
Dax:Like everything we do in the way we do things, we can find examples of big companies doing it the exact same way. I kind of feel like that just turns into a thing where people say like, oh, what you're saying doesn't work at scale. You can't really argue with them.
Adam:So all you're saying like, intuition about how things should be built today, I've assumed that was just for little teams, and
Dax:I just don't understand big teams. You're saying that might apply to big teams as well? Yeah. I kind of, like it's kinda taken for granted that the big team should is inevitable or has to exist or they have to operate a certain way. But I know teams that are operating at massive scale, and their system doesn't look too different from anything you or I do.
Dax:Yeah. It's a little more advanced because it has more years and more maturity. But, yeah, they're doing everything the same way that we're doing. So I mean, that's the that's
Adam:the thing about this way of building is this, like, how much leverage every individual has. And and just as a team, how much smaller you can be and accomplish so much more. I don't know how it all plays out, but I can't I can't help but think that, like, there's this whole wave of disruption where teams that are 5% the size of big companies teams are just completely cleaning up because they just have so much less to deal with and such a smaller footprint. And just like the fidelity of communication is so much higher when you have a small team. I mean, like, ideally, it's one person's brain.
Adam:Like, everything can float through there. If one person could accomplish all of
Dax:it Yeah. That's the ideal company. It's one person.
Adam:Yeah. Right? Yeah. So as things trend that way, it just does seem like how are all these big companies gonna justify their giant teams when it gets easier and easier to build? I mean, it all kinda depends on these managed services that ultimately a big team, like the AWS team I don't know.
Adam:It's a bunch of little teams, really. Yeah. They're putting together this stuff that allows for that. So I don't know how that all plays in. It does seem like there's some, like, at the utility level, need for big companies to push this stuff forward, but it just opens up these doors where I feel like little startups that are tiny can accomplish more and more.
Adam:We we've got data points of that. It's just like they're little little dots on the timeline that don't get enough attention, I don't think.
Dax:Yeah. As think, again, just having been in a different mindset, the work that you do that we consider overhead or you should outsource at AWS, it feels really valuable when you're doing it at the company you're doing it at, because you're really solving problems, you're really unblocking stuff, you're really making stuff better. And it kind of when people say, when people like us are saying, Oh, like, you you shouldn't be doing any of that. It understandably feels like what are you talking about? That's like, obviously necessary.
Dax:And a lot of the quality comes from that. But I think the thing you realize when you slip over is there's just a million things you could be working on at any company. Oh, yeah. If you're working on this, if that goes away, there's just like a million things that you could be doing to make your product or company better. You're never gonna run out of work.
Dax:Always something better you could be doing.
Adam:So the more you can, like, select into the most valuable thing, the the better. Because there's always there's always that optimization problem. It's not going away. Interesting. I still don't know if I feel like I can explain how I think serverless or event driven applications are the future.
Adam:I always just go back to Simon Wardley on Twitter. He's like my my my anchor. Whenever I start doubting all this, I just go back to his tweets and I'm like, yeah, he's too smart. He gets it. Yeah.
Adam:Not that there's
Dax:not smart people on all sides. Adoption too. Yeah. Oh, yeah. Yeah.
Adam:I mean, he's covered, like, the whole cloud adoption side. I don't know. I there I I just I guess, like, what is the future for things like Kubernetes? I don't know what the theme of this episode is anymore. I'm just just, like, coming up with more thoughts.
Adam:The they're just bubbling the service. But I guess, like, are people deceived? Is there is it not the future? Because I know Simon Wardley has said things like, I think it's a distraction. I think the whole containerization obsession and Kubernetes obsession is a distraction that set back serverless quite a bit, using serverless as a term for kinda what we're talking about here.
Adam:Is that, like, is that how you view it that, like or is there a place for it alongside serverless? It just feels like there's a lot of smart people on both sides. They can't all be wrong.
Dax:Yeah. I think the way at least the way I felt is my whole career, I've been figuring out how to manage nodes with with less work. So back when we had physical servers, like how can I best manage them? Then we got like VMs, how can I best manage those nodes? Then we got containers, how can I best manage those nodes?
Dax:And Kubernetes came out and it is the best way to manage nodes or one of the best ways. Like there are some, HashiCorp thing is also very good, Nomad. But in the whole history of managing nodes, this is like, it's so good. It's so much better than any other stuff I've ever had to deal with, especially with like, you know, doing it through Terraform and all that. It is amazing.
Dax:But the thing that happened was, what if I what if someone told you, you actually don't have to manage nodes?
Adam:I was gonna say, what is a node?
Dax:Just like something that runs and that you're responsible for.
Adam:Okay. Okay. I already don't like it. Okay. Keep going.
Dax:Yeah. So I think that's why people love Kubernetes because they've been doing some flavor of managing nodes their whole career.
Adam:Yeah.
Dax:And it's always been a pain and Kubernetes makes it a lot easier. But the question is like, do we even need to manage those anymore? Because now there's a whole other option that's kinda coming out of left field that is very, very different. Yeah. And we don't need to do that, and these things look kinda, like, overly complicated or, like, why does this even exist?
Adam:Yeah. Yeah. It's it's funny. Like, my Twitter timeline is so it's split between what I feel like is this crazy complicated thing that people dove into with Kubernetes and then, like, deploy your whole app on Vercel and you don't need anything else. It's like the two polar I feel like opposites of, like, well, I look at Vercel and I'm like, there's more.
Adam:You need more to build apps. And then I look at Kubernetes and I'm like, I don't know what that is, but I don't I don't really I feel like that's too much to have to think about. Then I I see very little of that middle ground of what I think is this amazing way to build apps. I don't know.
Dax:I don't know.
Adam:Lots of thoughts.
Dax:I don't know. And it's it's I think it's also hard to to gauge. I think we're on Twitter, social media, etcetera. And that's like, I think, least for myself, that's where I get a feel for what's going on. But if you look at actual data for what's going on, it's like very different.
Dax:They're almost the opposite of anything anything we see. So so it's always tough.
Adam:So Twitter is is just a small I mean, it's a pretty small network, I guess, of people that actually get on Twitter and say anything. I mean, if it's, like, not even all the devs are on Twitter, like, what percentage of people on Twitter actually tweet? So yeah. That makes sense.
Dax:Yeah. Yeah. And Twitter tends to be, like, really front end heavy and, like, there's Yeah.
Adam:Why is that? We've talked about this before. What what what's that about? Like, your theory is that back end developers just have an amazing life and they don't need the Internet or social social media?
Dax:I have no idea. I mean, I think I'm mostly a back end
Adam:I think I have to. I mean, I I just am so slow at front end. I must be a back end developer. I don't know why else I'd be so bad at the front end.
Dax:Yeah. Sometimes I think I'm a good front end developer, then I see some stuff and I'm like, I actually have no idea how they did that. So I can't be a front end developer.
Adam:Do do you have any working theories for the the discrepancy? Why the public discourse, even like Hacker News and stuff? Well, maybe not as much. I don't get on there. I don't know.
Adam:It's been a long time. But it does seem like front end dev just sort of dominates the conversation.
Dax:Yeah. I think it might be I want I'm not sure if it's like an age thing. Like, if you're earlier in your career, I think you're more likely to be a front end engineer because I I was exactly the same way. You wanna get you wanna, like, learn how to build stuff. You want that immediate feedback that you're making progress.
Dax:End is, like, the best place to do that. And I think people that are maybe earlier in their career are also more likely to be on Twitter. I'm I'm having this building can fit into this, like, mostly front end with a little back end model that, you know, Verzel is great for.
Adam:Yeah. I'm having this flashback. Like, I've heard someone say that, and think it was you. I think we've had this conversation. I'm just remembering you say it makes sense.
Adam:Like, the feedback loop, if you're or maybe it was someone else actually. It could have been someone else that talked about, like, when you're building back end stuff, there's very little that you can, like, iterate and see. It's so much easier to just build a front end app and, like, you change the CSS and you see the button change and, like, there's that immediate loop. Whereas back end stuff is a little more, like, hard to get that, I guess, that feedback. You got the right JSON response.
Adam:You're right. Yeah. Exactly. I I love back end work. I mean, I love, obviously, cloud stuff.
Adam:I just think every time I do front end development, I get sucked into it for, like, to try and do the simplest of things. Alright. I don't know how long we've been talking. Is this an episode, Dax? This is gonna be a little rough.
Adam:I'm just gonna be honest. These first episodes, figuring out a new format.
Dax:I think it'll be good.
Adam:I think it's gonna be great. I I'm excited about it.
Dax:A little rough, but I think it'll be good. Yeah.
Adam:Yeah. A little rough, but it'll
Dax:be good.
Adam:We're gonna just keep doing it, and I I think that's the trick is, like, you just keep doing stuff, and it ends up really good eventually. Yeah. Yeah. Do have any other thoughts on the edge? That's what we started talking about.
Dax:Yeah. Do I figure how we should title these, like Yeah.
Adam:This one's gonna be They just
Dax:be like comma separated list of all the topics.
Adam:Yeah. That works for me. There was stuff I wanted to to kinda dig at, like, in terms of the edge and how it relates, like, AWS services. I think of, like a lot of the problem I have with the edge is, like so LambdaEdge, you can do all the Lambda e things, node runtime, like, it's I think it's constrained a little bit, maybe. You can only do node and Python or something.
Adam:I don't know. Not all the runtimes.
Dax:There's, like, really weird restrictions. I don't know if you know this, but LambdaEdge cannot have environment variables. Oh, really?
Adam:I feel like it's
Dax:such a pain.
Adam:Yeah. I feel like I've done some LambdaEdge stuff and I guess I never noticed, but that seems like a pretty big thing you would notice.
Dax:But this some really weird stuff in SST where we, like, let you think there's environment variables, then we do, like, a string replace in your code Wow. After it deploys.
Adam:Okay. Yeah. So LambdaEdge and then but that's only in, like, 14 locate it's, like, more than the regions but less than the actual edge, like CloudFront edges, nodes, whatever. Right? LambdaEdge doesn't actually run it sits like between the regions and then all the actual edge locations.
Dax:Yeah. And then there's CloudFront versions you can
Adam:do nothing in.
Dax:Is different.
Adam:Yeah. Yeah. But then, like, if you wanna use the CloudFront functions where you're running compute actually at the edge, it's like you can't interact with the page body. Like, you can only kinda, like, change the headers and stuff, and I just don't know I guess there's things that that's good for. But it's
Dax:just limited to, like, a five millisecond runtime or something. It's like something
Adam:Oh, yeah. It's super short. Yeah. Yeah. So is that where cloud I've never played with Cloudflare workers.
Adam:Are they more, like, actually at the edge and, actually, you can do stuff? Is there there's, like, advantages there?
Dax:Yeah. I have a whole thing on this. So upfront disclosure, Cloudflare is the biggest position in my portfolio. Like, I own a ton of Cloudflare.
Adam:Waiting for, like, Cloudflare sponsored this episode. I was excited. Like, oh, that's cool. Okay. So biggest so you're a big Cloudflare fan.
Adam:You're an investor and and that we got it. Disclaimed. I've never had to Yeah.
Dax:Disclaimed. Something.
Adam:I'm being really awkward now because I've never had to do this on a podcast. Yeah. Okay. We've done it. We've done the disclaimer cloud player.
Adam:Legal, you can step away. We okay. Go ahead, Dax.
Dax:Yeah. So, like, the but that's all backed by, I think, my just my excitement around what they're doing. So I think, like, we all love the serverless world. I think realistically today, AWS is the only one that has a complete serverless platform. Like it's more than just functions, right?
Dax:It's functions, queues, all the stuff you need to do a full application. And I feel like Cloudflare is the only other company really getting to that level of completeness. A lot of that stuff is, like, still in preview and, you know, not widely accessible. I think they still have, like, five plus years to go before, like, this competition really shows up. Yeah.
Dax:But yeah, I love their functions platform. I think it makes a lot of sense. They have really good options. They, it all works well, nicely well together. I think with AWS, it's, it always feels like it grew more organically and accidentally.
Dax:And with Cloudflare, it was more like, okay, we already know serverless exists and we're like bought into this concept. What is like the ideal vision? They got to kind
Adam:of design it and build it when it was a thing already. Like they had more of a target, whereas AWS kind of invented it sort of
Dax:in Yeah. Yeah, exactly. So it's like a it's a lot cleaner and there's like less weirdness with everything.
Adam:But when
Dax:I I feel hear like the only ones that can be so I think you and I believe that this is like the future of way most applications will be built. Yeah. AWS is like so well positioned. But yeah, they're like runtime. So they have their own runtime.
Dax:So the downside is you can't use most node modules, like most NPM packages. Right. Is that a downside? I think it's kind like a good filter. Yeah.
Dax:Kind of prevents you from using stuff that isn't great. But you can more or less build whatever you want within their runtime. I think we're all gonna be a little annoyed with all these different runtimes. Like you got Node, which we're all familiar with. Now Cloudflare has their own.
Dax:There's like Deno and then it was Bunn and Bunn is gonna be fully compatible. So that might not be an issue. So it's like an explosion of runtimes right now, which is kind of annoying. But yeah, I think their setup is really good. It makes a lot of sense.
Dax:It's really focused on this event driven thing. I don't know how many people are actually using it, but
Adam:pretty Well, my one, I guess my one big question. When I hear that like, there is no infrastructure as code. Yeah. How do you actually, are you console clicking? Like, what do you, how are you defining apps for So they have,
Dax:I wouldn't call it infrastructure as code. It's more like a framework for building Cloudflare apps. And there's like a CLI tool associated Oh, with And that's the CLI tool will do deployments. Yeah.
Adam:Okay. So, and you're like, you're building out, like you're just writing TypeScript files or something and using this library? Exactly.
Dax:It's like, it's like a, it's more opinionated than you get with AWS, because AWS, you kinda have to figure out how to structure things, but have like 30% more of a framework. And there's a clear way of how you structure applications, how you break stuff apart, all gets deployed as these like individual functions that run. And there's options for like queues and like, like, an s three equivalent and, like, a date some some database options as well.
Adam:Okay. I I just I think you've picked my curiosity. Peeked? Picked?
Dax:I don't know. You've you've got
Adam:me curious if there is actually some kind of I just imagine, like, zipping up things and, like, uploading them through a web UI, and that's how you define a Cloudflare application. That was just sort of a non starter in my mind. That's where my mind goes when I hear no infrastructure's code. But this sounds like not Right? And it makes sense Yeah.
Adam:I guess, if people like enjoy building on it. It wouldn't be terrible. So I shouldn't just jump to the, like, most terrible possibility.
Dax:Yeah. It doesn't cover everything and I do I think they do need to add some native IAC thing in there. That that's a that's a huge task. Oh, yeah. They might already be working on it, but yeah.
Adam:Okay. That's enough of our edge talk and whatever else we talked about. We're just gonna we're gonna end it. I don't know. Goodbye, Dax.
Adam:I don't know. What what do I say at the end? I don't know. It's so hard.
Creators and Guests
