Streamlining global ingress with ngrok

• ngrok: ingress as a service - https://ngrok.com
• Introducing ngrok-go - https://ngrok.com/blog-post/ngrok-go
• ngrok-go library - https://github.com/ngrok/ngrok-go
• Introducing ngrok-rs - https://ngrok.com/blog-post/ngrok-rs
• Vim plugin for GitHub CoPilot - https://github.com/github/copilot.vim
• Stripe's Embeddable Payment Components - https://stripe.com/docs/payments/payment-element

​ 

Colin: Welcome to Build and Learn. My name is Colin.

CJ: And I'm CJ and we are excited to sit down with Alan Trive today, the founder and CEO of En Groc. We're gonna talk about. The future of software development. We're gonna talk about how Enro is solving all of your problems and abstracting away the tricky parts of networking and building your application. We'll talk about global ingress and lots of other fun stuff. So let's get into the episode.

Colin: A lot of our clients were like, Hey, we have Salesforce and we. have these new iPhone things that came out and we want an app that's, tying into our C R M and our cms. And so it was doing a lot of, early web hook stuff. a lot of pubsub, hubub and like integrations and getting into ultimately what brought me into Techstars was we were trying to build what eventually became like Zapier. a little bit more like a SendGrid for integrations though, or Twilio, like you drop us into your code base and turns out, you have to raise a lot of money for people to want to drop an entire integration framework into their code base. But, yeah, mostly a lot of the things that you guys have run into with like web hooks.fyi and things where it's like everyone does this differently and so we're gonna make the one API that standardizes all of it and turns out, in 20. 12 you. It just wasn't the same as it is today. And now you have like APIs coming out that are trying to do this again, like Merge and Finch and all these different apps that are going after, these are all the payroll APIs. Here's one API to do all payroll APIs. We were like trying to do all of them and it was just a lot. And I think that's where I, I've been in the webhooks Google group since whenever, at first, whenever Jeff started that. So it's I've just been like on the edges of just watching, message passing on the internet. Just still the same, still happens still,

Alan: hasn't changed too much. Yeah. Do you know Jeff?

Colin: just a little bit. we've got some like shared, co-working background and web hooks and things,

Alan: yeah. I worked with Jeff back at Twilio. yeah, it's interesting. That's, it's definitely interesting, what you're talking about, a building, an API that like covers up, a bunch of APIs. It's. Kind of like the industry creating a standard or someone in the industry trying to create a standard api. I'm pretty skeptical of those. I think, if you look at technologies like. Terraform where it would've been really easy for them to say there's a storage bucket resource and we'll abstract it over GCP and Azure and aws. And they like explicitly chose not to do it because I think they recognized, and I think a lot of other people have recognized that it is very, very hard to abstract around those APIs. It's incredibly hard. You'd need something to be like almost, purely a commodity and very little differentiation before that thing starts to make sense.

Colin: and most of those services are trying to differentiate, and so they all come out with what makes them different. And then

Alan: Exactly. So you're not aligned. right. Um, which is, which is really interesting as well.

CJ: Even with even with standards like OAuth, right? Like I assume you're running into that now trying to build like the OAuth pieces to the ngrok infrastructures. oh yeah, we wanna do OAuth. But everyone does it just a little bit differently with little different scopes and a little different, like data you get back and a little bit of different, is it in the header or is it in like the response or whatever? Yeah, just trying to paper over that seems impossible.

Alan: Yeah. it's interesting, just for those listening, EDRO, has added some recent capabilities where you can basically put OAuth in front of anything that you expose via edro. You basically tell it, put Google in front and it will OAuth or redirect you to Google. and then back. we've implemented a number of different providers, for OAuth. And you're right, that it's interesting the OAuth spec. Is mostly followed by everyone to the point where like you can pretty much build the same thing and it works for everyone. The place where all the providers differ is around things that the spec very explicitly says, this is not our problem, right? this is implementation defined, and so like you go figure it out. and so that makes sense that everyone like has diverged there into like slightly different ways. And for the identity piece, of course, like a bunch of folks got together and said cool, let's standardize the scopes and the thing that's returned into what has become open, ID connect, on top of OAuth, but even within the, so like within the spec, yes, there are some places where it definitely differs a little bit. the place where we saw the most deviation from the spec was, air codes. Air codes are the least well followed thing, in the spec. They're the place where the spec says what is correct, or like what is to be expected and the least people actually implement it correctly. Whereas scopes, everyone does a different thing, but the spec says, You can do whatever you want with scopes. They're entirely yours to define. So that makes sense. But the air codes are one where the spec has some opinions and it's still not tremendously well followed.

CJ: I watched some of your talk at that conference about error handling, and I'm curious if this was like part of it, but basically that like I feel like errors are so often just like a. a second. I don't know, the, it's like a last minute thing that, yeah, it's an afterthought. And Deb's tried to throw it in like at the last second, oh, let's add some air handling or whatever. But the reality is that they should be treated as a first class citizen, the same way you're treating a return type or whatever from any method.

Alan: it's one of the things that I'm most proud of about, the internal architecture of Enro is our error handling system. Every, and I think I talk about it a little bit at, In the talk from that conference. but I don't go into, quite a lot of detail. There is every single error that N Rock returns and every one of them. Every, sorry, user facing error. Something that we expect a user to see has a unique error code that is defined in we have a. Essentially like a big manifest where every single error that the product returns is defined in there, which is at this point, like thousands, right? and so there's a unique code for everyone. And our system basically like reads that manifest and then like code generates type safe findings to all the different languages, that we use internally. For folks to spit out, errors that, use that particular, format. it's really meaningful because, those, the things that are returned are objects that are specially annotated, so you know that they're a user facing air code. So all the air handling can treat them differently. There can be special metrics around them and really, really beneficial from a. You know, from a product management standpoint of like, you can go and like into our observability and you're like, what do people, what's the air people hit the most cool. we know, right? Like we absolutely know exactly what that is. We know the biggest stumbling block to using the product. and so if you think about like growth or just, user experience, understanding what. What people are doing wrong is, is super helpful. the other place where it really, provides a tremendous amount of benefit is, from a customer success, customer support standpoint of, what we're trying to do there is make sure that when people write in, there's nothing more frustrating than getting an error report where someone's it doesn't work. And here's vaguely the error that I got, and you're like, I can't help you. Like I have to like, send you a bunch of emails to ask you like how to duplicate it and please tell me. but when people send us an air code, we know exactly like the line of code where like they, they encountered the air, which is really beneficial to getting quickly to the root of the problem. so couple, couple huge benefits that way. And the last one is, really. Developers, like when we encount an air message, like what is the first thing that you guys do? you copy and paste that thing into Google and you're like, what? What shows up? and we wanted those things to be unique strings that you could put into Google that no one else on the internet would have. So you put them into Google and you get back like our air pages where we can give you like the best documentation, tell you exactly like what went wrong and how to help yourself get out of whatever, you know, area you were encountering.

Colin: That's awesome. Yeah. I think a lot of people think of like an API or software as like having a contract and we think about all the things that can go right, but we don't spend as much time thinking about, like you just mentioned, to the error codes, the contract of what happens when something's wrong. how do we help write a guide or even just include the information in the error itself on what. What is missing? What needs to happen next? having written lots of APIs, it's okay, if I'm trying to create something, what do we send back? If you're missing data, what do we send back if it's already been created, like the, obviously we have HTTP status codes and things, but even those can be, pretty vague at times. And you gotta come up with these like first class. Error objects. I know some APIs and client libraries do a really good job of this. and it's obviously you guys have a high, high bar for that developer experience when you do that. since we're just jumping in here. would love to just set the stage for people who might not know what ING Groc is. I think most people aren't familiar with it. for things like local ingress for, I have a rail server running on port 3000 and I want to op, add that to the web. I wanna expose that to, to receive web hooks. Or maybe I want to have a preview app so that CJ can go hit this endpoint and view the app that I'm running. But what would you add to that? what does enro look like today? and what are developers using it for?

Alan: thanks so much for that intro. That's, really helpful. yeah, en groc, that's definitely where En Groc started was, about. Where we started was web hook development and testing. I started my professional career at Twilio, one of the companies on the forefront of using web hooks to drive behavior. And, just, it was a frustrating experience to develop with, develop on that platform if you couldn't get those web hooks directly to things that were running locally. over the years, what we. What we found and discovered was if you think more broadly about that problem that Enro was solving, Enro was creating ingress to your local. machine, right? It was accepting traffic from the internet and it was routing it to the application that was running on your laptop. But that's really just one specific problem in a more general problem, which is how do I get traffic from the internet and send it to my application running anywhere, right? It could be running on my laptop, it could be running on my raspberry pie. It could be running in a container in a CI job for 30 minutes, or it could be running in production, serving I don't know, all of reddit.com or whatever it happens to be, but like fundamentally the problem. Of getting traffic in from the internet and routing it to your application is the same no matter, sorry, it is different, but the kind of like fundamental primitive that you use to do it, is the same. in, interestingly, I guess I'll walk that back a little bit, is that, that, what's happening is very similar, but the tools that developers have, to use to actually make it happen in those like four different scenarios that I outlined are all wildly different, right? and that's really where we've moved over time is, to start handling this production traffic to being part of your, production infrastructure, your CI infrastructure to create ingress to your applications no matter when or how or where they're running. It doesn't matter what platform or any of that. it's very frustrating for developers to have something that works in development and not being able to take it to production, have to like invent something entirely new to get there, and that's really what we're, we're trying to solve for folks.

CJ: It seems like the messaging. That. I think a lot of people are still thinking when they hear Enro, they continue to think of like, how do I build a local tunnel to my machine? But I think the key sort of message that I have heard, like the shift is oh, Enro isn't just for local development anymore. Like Enro can be used anywhere to do this global ingress to your application. So you can like, Stop worrying about your whatever reverse proxy solution that you're cobbling together instead. is that accurate that you could think of enro maybe the way that I think of it as another way to do the same thing that N Engine X might do. And obviously as someone who wants to spend time building on the web, I am not fiddling with devs. Like I actually hate N Engine X just because it's such a pain to, to get everything right and, so yeah, just how can we think about Enoc relative to a tool like Engine X?

Alan: that's a really good intro. yeah, what we're calling Enro is ingress as a service, right? It is, it is that piece of getting traffic into your network, and or into your application and basically running it as a globally distributed service for you. you were asking about nGenx. It's interesting that is, if you're like putting applications out on the internet, that is certainly a piece, right? Where That you're using to do it, but you often have a number of other pieces, right? You're layering in front maybe a content delivery network. You're maybe layering in front some kind of, DDoS protection. you may be layering in front, some kind of like caching proxy. You might have an identity aware proxy to do some piece of authentication for you. You often have like layer four firewall rules. You have ips and TLS certificates, and maybe an integration with Let's Encrypt and the list goes on where you're like, as a, I remember, being, baby application developer, like back in the day and learning, Apache and then Engine X to put my web applications on the internet and just being frustrated that it was something that like I didn't want to learn. And I didn't like, it wasn't like core to the thing that I was doing that I wanted to deliver, which was the application. And that's really the power is like we're, enro is talking about collapsing all of those into a unified layer that is tremendously developer friendly for you to basically put your application on and on the internet, in a way that you want, secured in the way that you want, without you having to worry about all of those low level pieces. The analogy that, we've been using is that to put applications on the internet. you're working with, like the assembly language of networking. you're really working with a lot of these low level primitives like DNS and tcp, and, ips and. TLS certificates and things that as an application developer like you don't really care about, right? you want a domain with, you know, an HTPs s certificate in front of it to receive the traffic closest to your customers and maybe enforce some policy, some authentication and things like that. But the infrastructure run it and the configuration to it should be. A lot simpler than it is right now. And we're, what we think we're doing, at enro is really building that high level language to abstract that, assembly language.

CJ: I feel like there is a trend in modern development where it's Let's give you these drop-in tools or drop-in components that replace like a lot of work that you otherwise would've had to do. So on the, for the Stripe example, you're getting these embedable payment components where you can just drop in some React component and that will give you these secure eye frames that. Will handle lots of like validation and collecting different payment method types and localizing, and it's like offloading a lot of the work of collecting payment to Stripe. And in this case it's like offloading a lot of the network level things to en groc where you can just install this agent, set up some connect handlers and, it seems like you've got. Go and rust. And I saw some hints of maybe JavaScript coming soon. so it's a couple of lines that you add when you're setting up your server that's gonna listen and then from there en rock will handle abstracting away or offloading like all of this other complexity. And one of the things that I'm like curious to double click on is, The, the, I think you call them points of presence maybe, or the global globally distributed concept here, and like, how should we think about that relative to like edge functions or Dino deploy or, like having, yeah, having your, your, your application deployed to the edge versus having ingress happening at the edge and then routing that to some server that might be, Living in Virginia or Washington or something.

Alan: that's a good question. you're right. We've built the Go and Rust SDKs. We're working on a couple of other ones. Those are a more modern way of using NRO that, I don't think a lot of people are familiar with, where you're basically embedding NRO directly into your application. You don't have this, if you're like used to using it, you used to have a separate executable that you would download and now you have a library where you basically, Ask and it returns to something that looks and feels exactly like a socket object. but it's not listening on a local port. It's listening on all of our global points of presence all around the world. in terms of like how to think about it versus edge functions, or like deploying your application to the edge. what I would say is. When you're building an application, sometimes deploying applications to the edge makes sense, and sometimes like having them, not deployed to the edge makes sense. deploying them to the edge comes with, basically puts you in the space of as soon as you have to talk to storage, you have the problem of cool, I have a globally distributed storage problem. r really, I think where we're going to end up. Is, there are two possible futures there. One is, one in which like our storage layers become so good that we can run our entire applications like fully distributed at the edge. And like all of the synchronization problems happen in like this global storage layer, right? Of what is like the next iteration of something like spanner and is it good enough that We can commoditize it and give developers really simple APIs where they can just call this stuff anywhere around the world and give them, hopefully the right APIs to make. Cuz you know, even with a system like Spanner, you still, the application developer is making the, like the kind of like cap theory trade-offs, right? Of do I want consistency? Do I want, availability, partition tolerance. that's one world. the other is, that we think about applications being, a little more. Amorphous in terms of being able to be split between an origin application and a piece of it that it, it pushes out to the global edge. And like right now, I think a lot of developers are thinking about those in like separate ways, but, one of the things that we're really excited about, things like the End Rock SDKs allowing you to do is you can specify a lot of the configuration in those SDKs and they get pushed. To our global edge. and that's something that's like a stark contrast to like setting things up with a technology like engine X or something like that in that the application in our world has control over the edge, right? It has a defined API to say, like, when I come online, like the. The reverse proxy, the ingress point is an extension of the application. I have an API to set up and control that in the way that I want. and I think that will get us into a world where applications, Can push configuration and logic, basically having like pieces of wassom or stuff that they're like, yeah, you can execute this out at the global edge because, it doesn't require like stateful handling or it requires a minimal amount of local stateful handling or things like that. and so we're we'll end up giving developers a little bit more of a seamless experience where they have the control to basically decide, this stuff runs there and this stuff runs, here.

CJ: Got it. So you could terminate, ssl, and you can do your authentication checks and you can. Do some basic things at the edge, and then once you've handled that, then and when you're ready to talk to the database, then you could like, all right, now we will make the trek, the tcp trek all the way across the internet and talk to the underlying the underlying application server.

Alan: Yeah, that, that may be the right model. It may not be the right model. it's a little hard to say at, at this point, but, I think it's like one of those two models or like a hybrid of them where you're pushing like some control out there. cuz like at the end of the day you're just making these trade offs about, you're just making distributed systems trade-offs, right? Have you guys like, in, in your development, it sounds like we were talking a little bit at the beginning about, the kind of, development that you're doing. CJ you said you were doing a lot of kind of like web application development, a lot of, backend stuff, things like Ruby on Rails, but also some front end pieces. And Colin, you said you, you'd been doing, some similar things as well. I'm curious, do both of you like have that experience of working with, with those kind of, of like setting that stuff up yourselves? Or did you end up like working with other people who would set those things up for you?

Colin: For me it was, usually I'm the one on a team, like for consulting and things like that. Before I was at Orbit, it was not having an infrastructure or DevOps team. So I was doing everything myself. And you really get to learn and appreciate like, All the things that not only do you have to learn them once, but you have to learn them for each clot provider or each, infrastructure stack that you're working with. So the, and then you end up feeling like you're learning this stuff over again each time, or there's like a small differentiation that makes this one better than the other one that you used to is. and so I do like that idea, like standardizing it cuz we're seeing a lot. It'll be interesting to see, like a lot of things have been being automated, I guess is the right word. But like with GitHub co-pilot and LLMs, like everyone's so excited about the idea that we're gonna not have to write every line of code anymore. But it's guess what? There's now even more infrastructure and more tools and more stuff in between those apps that we have to deal with there's definitely a lot of tools that I'm starting to see that with like secure data transfer and stuff like that. It's I definitely don't wanna do that myself. if you were to build an app like a WhatsApp today with having like end-to-end encryption between two people talking back and forth, and that might be a product someone builds today. Like what? Tech stack makes sense there. it's not quite the same thing that we're talking about today around local tunneling and things like that, but it is a very similar thing where it's let's say GitHub co-pilots helping me build a chat app with like sockets and things like that, you're in, you're probably building a very insecure. chat app to start or, internet of Insecure things would be. The other way to think of it is like a lot of things get shipped with not a lot of thought around the security piece of it. and so I'm really excited to see like what things we can do to help automate and read. We, approach those things, so that they don't have to be scary. I think, like I try not to do the DevOps stuff these days. I think the jokes of dev, oops, engineer more than DevOps, its like, what check, what one thing did I forget to look at? What one, one setting did I forget that, I'm thinking that I'm secure, but like the front door's wide open, even though I followed like this long list of security and ingress, like checklists.

CJ: to give some people nightmares, I think Back in the day, I would go on Digital Ocean and spin up a droplet and then just SSH into it and manually set up, passenger and engine X and Apache, like all these things. And like immediately started getting hacked. Like just started to get pummeled by spammers and whatever. And then, if we, rewind even further, I remember setting up, like on Windows server, like setting up IIS to like, open up certain ports so that they can like, talk to different applications and, someone re goes down into the basement and restarts the physical machine that was running Windows server. It's okay, we've come a long way since then. And, even back. pre this is pre and, en rock. I'm sure. It was like, oh, if I want to show someone my local running web application, I'm gonna log into my, lo my router and set up, nat address forwarding so that I can like, poke a hole in my home router so that people can hit my machine on, port 80, 80 or whatever. So I think y most recently I've been really depending a lot on tools like Heroku and tools like Versace to manage most of that. And like more recently using things like CloudFlare to provide, these really fancy SSL termination things where I can have wildcard domains and set up all of this, I don't know, more advanced infrastructure for building a platform, but, for the most part, yeah, it's been one of those things where I've been bitten so many times by building insecure surfaces that, I now try to just, stay in my lane and build tools closer to the front end. Then, then, yeah, I then I thought that I could back in the day, I dunno, may, maybe now I can just drop in en gro Ruby and, depend on the security and let Alan do all the heavy lifting of figuring out how to not get attacked.

Alan: that's really what we want, folks to do. We, the reason, the kind of like engineer that I've been for a very long time, and the thing that like really has always made me excited is about building a. Tools and platforms and infrastructure for developers so that there's nothing more exciting than for me than like solving problems and watching developers like never have to deal with them ever again. and that's, that ethos is really what started N Groc and it's what continues it today is, how do we take these problems away, so that, folks don't have to like, think about the things that they definitely don't wanna be thinking about.

CJ: For

Colin: Yeah, and a lot of us have these experiences of tinkering and learning and I do wonder. Because a lot of these newer tools make it a little bit harder to tinker. Like it's amazing to be able to deploy to, a render a fly, but you're not actually messing with the digital ocean box like you, were talking about there. But where do you then learn these things? Because I don't like someone coming out of a bootcamp might learn the application stack, but they're not necessarily getting a lot of time or experience with some of this other stuff. And, I haven't seen. Too many dev like DevOps boot camps or security boot camps, things like that. cause that would even like a finishing school for security, right? it's something that I would take just to know what gaps do I have in my knowledge. Because very similarly, like anything, we used to do a lot of WordPress stuff and Any website with a slash WP admin was just going to be added to a list that was gonna get attacked at some point. and then you start tinkering around with Apache or Engine X and things like that. but you actually could, it's kinda like tinkering with cars like you used to be able to actually work on your car and today. Very difficult to work on your own car. And as we get to EVs and things, it's gonna be near impossible too, especially when, those cars are mostly software and, a whole bunch of batteries, But, it, it'll be interesting to see like where this goes and what sorts of things, change. Is there anything that like you're particularly excited about? Alan, as far as like maybe future looking things or, not necessarily add and groc or if there's stuff that you guys are cooking up over there.

Alan: Oh man, there's so much to be excited about today. one of the things that's really excited about is that, it's interesting what you said about, folks don't have, they don't, someone coming out of bootcamp may not learn a lot of those things. that's true. But maybe that's okay. Like maybe we're like headed for a world where really that's okay. and if you like rewind a little bit, you're like, most developers like today don't think about like memory management, but we're all like, that's a nice thing. Mo most of us don't really want to think about that. and most of us don't think in assembly language anymore, and like maybe that's okay too. so I, I don't know it, there, there are always these sets of problems that. Every, everything in, in software engineering is a leaky abstraction. When your problem gets thorny enough where you're like, I gotta go below, I gotta understand like the piece underneath and the piece underneath and the piece underneath. but I think, as the industry has matured and our tools and our infrastructure has gotten better, we have gotten to a place where you have to get into those layers less and less. Just because we've gotten. We've hardened those under underlying layers and made the APIs to them so much better than they used to be. And I'm optimistic that a lot of this stuff will, move in that direction as well. And that a lot of the problems that we solve today of that, you would do in like a DevOps finishing school if one existed, are things that I hope the next generation dev developers like never has to think about. and that there, there are a few of us who like. Spend our time there and that, if people want to like, understand those things, just like if someone like wants to go and understand the details of the Linux kernel, they can, but if they're like building web applications, like they shouldn't have to and we shouldn't expect them to. so I don't know. I'm optimistic and excited about a future where, those are, those become details that folks don't have to think about. So I'm really excited about this, new generation of, NextGen Heroku folks who are thinking about, applications as a service again. and. Yeah, I don't know. I'm excited about that. What else am I excited about? There's a lot to be excited about in software engineering. web assembly is certainly an area that's obviously really exciting. obviously LMS and ML in general are, a really cool area to be excited about too. So there's a lot that's going on.

CJ: One of the things that I've noticed over the last, probably two years-ish, is that there are a lot of new developers coming online that are building with tools like Relet where they're actually like building something in the cloud and running it in the cloud, and that is where they're. Hosting it and deploying it and everything. It's like part of rep. And so I'm curious, if you have any intuition or if you've seen the same thing, around like the future of this next gen of developers and will they just Yeah. do we think everything is just gonna be some cloud-based i d e and you just say go, and then it's running like for you and anyone can use it. I don't know. Especially like. They have that ghost writer, kind of their version of copilot that's built in. So I don't know, there's some really cool stuff happening over there. .

Alan: this is, this is the space of replica and code spaces and glitch and that kind of like set of tools. they're exciting. in general, I think as an industry we should be tremendously excited about anything that lowers the barrier to entry to creating new, new software. and so in general, like. that's what we're doing at Enro is trying to lower that barrier to entry, to like building applications and getting them online. and, really excited that you can use Enro with platforms like Rep and Glitch and things like that to get yourself this, global ingress with, functionality that can push out to the edge. But in general, like. Anything that lets people like lower the vari entry and create new software and get more people into, to the space being creative and building new stuff. I think, that's one of the things that's most exciting about our industry is getting to see all the people experimenting with all of the new and cool ways that, we could potentially build software together. That's all really exciting to me.

Colin: Yeah, I think we like to geek out on the tools and the processes and things, but ultimately we're doing all of this to build like a product for customers, right? And so sometimes it's Does the customer actually know how we're getting the web hooks delivered to the app? They do not care. they just want the outcome, right? The, if it's a dog walking app, they, or, Uber, your Uber driver's showing up. Like you want to get a notification when that's happening and, they're not worried about what. the infrastructure looks like underneath. So I think, we tr we've been thinking in this show in terms of like, how do we build and learn, as developers, like how do we develop ourselves, not just yes we can go learn new languages and things like that, but it's like, what other things are we bringing to the table and think, like thinking about product and the developer experience all the way down to what error codes do we get? You know that's the same for a product. if your Uber card just doesn't show up, you can't just say something happened, right? It's gotta be like, why did the car not show up? And what can I do about it? Who can I reach out to? An Airbnb got canceled on me for this weekend and it was like, You know, you get a text that's your Airbnb was canceled, and then you're like, great, now I gotta go, follow the, literally the stack trace of okay, go click on the link. Let's go open Airbnb, let's go find out what happened. And, that is so far removed from whatever tech stack Airbnb is using under the Hut. So, um, definitely as you're listening to this, remember who you're building for, remember what you're building, like what problem you're trying to solve for, and, use tools like incorrect to Get rid of some of those things, the headaches, or at least make them standardized so that, on the next project you work on, you have, a tool that you can reach for sure.

Alan: Yeah, like I said, I'm excited about. any tools and any infrastructure that, that make it easier? I think they're all like places where gets more people into software development. It means more people are trying new things. we're as an industry, as a. A, global populace, like the speed of innovation is tied to how quickly can we experiment, like how many people can experiment. And so as we see like these new technologies and services that lower that cost to experimentation, we're getting more shots at building more new and cool things. And that's something that we should all be really excited about.

CJ: Totally. Yeah. I think this also dovetails really nicely with the whole no-code movement, which we've talked a lot. And I think, I, when I first thought about NRO and no code, I thought, oh, there's probably not that many people who are, opening up the terminal and running NRO and setting up a local tunnel so they could do no code stuff because they're probably using some application somewhere. But the reality is that now that might be part of their stack in some way or another. okay, we're, building this no code thing with bubble, but I need. I don't know. I need to test something. Yeah, I need to test web hooks or whatever. And, there, there was a bunch of like use cases, I think. That I, recently bumped into within groc too, where I was like, oh, I want to test something locally, but it needs to have hdps s and I don't wanna have to figure out how to set up my SSL cert. And so I'm just gonna try on in groc, cuz I know that it gives me that Hdps s endpoint that I can use instead so that I can go verify my Apple Pay domain or whatever. It's like a test, like some Apple Pay thing locally. So there's, yeah, I think there's, I dunno, there, there's always gonna be like use cases where people who are building cool stuff are gonna need these tools. But yeah, it is a incredibly exciting time to be alive. And I also like every time that GitHub co-pilot completes anything for me that is like non-trivial or more than a line, I'm just like, whoa, this is so cool. still, after a year of using it almost every day, it's, it still blows my mind. And, yeah, I think it is definitely a really exciting time to be alive. For sure.

Alan: I don't know that I've talked to anyone who's used GitHub co-pilot for a year. do you feel faster when you use it?

CJ: Oh yeah, way faster. I think that, so I, I initially set it up in Neo Vim, so you don't just have to use via vias code. So if you're using Neo Vim, go download T Pope's Get Hope co-pilot thing. There's a way to set it up, and it basically com like replaced all of my. My sort of dumb auto completion. and so now it's, it's very good and I'm now at the point where I'm learning type script and it helps a ton with type script. But circling back to one of your earlier points about copying and pasting errors, like the errors you get from TypeScript are so they're, yeah. They're impossible to understand. They're possible to Google. They're very challenging. So I'm like, I feel like I'm still on the frustrating part of the learning curve with type script, but,

Colin: Are you getting, you're getting some type is not a type errors.

CJ: Yeah. Or it's always like something is not any, you can't assign something to any, cuz we, we have it, we have all of the restrictions cranked, like really high. So it has to be, yeah, all the types have to be very happy with each other. And but yeah, co-pilot has been making all of that much, much faster. And when I was at Stripe, we were working in lots of different programming languages, go php, java.net. Ruby python. It was, we were all over the place in sw context switching between them was sometimes tricky and GitHub co-pilots like, oh yeah, I know that language and I know that language. Did I know that last, like, you know, kind of the, uh, the Rosetta Stone for you to sit there and help you through okay, what is the syntax for this again? but yeah, it's made, it's definitely made me faster for sure.

Alan: It's, it's again, like another thing that I'm like really excited about because it fits into that same theme of things that make software development more accessible, right? Things that give, and for those who are, those of us who are already like more seasoned software developers, it gives us leverage, right? To be able to like, move faster, and build things that otherwise, like maybe would've taken us longer. Maybe we have to build a team to build those things. In some ways, a lot of modern software development is constrained based on the complexity of the things that we build. And, the complexity of the applications that we build, sorry, like the functionality, like how much stuff like an application can do is constrained by like how complex of a. Of like a code base you can manage. And we've built, like so many of our tools are just about trying to manage that complexity. Like how do we create abstractions so we can hide some of that complexity and not think about it as we like, deal with the rest of the problem. and like software engineering and management, of like building engineering organizations is about like siloing that complexity like within humans and within teams, right? Of like, how do we create a team who can own this like problem so the other teams don't have to think about it? And technologies like co-pilot are really exciting because they give everyone leverage, which means like the scope of the things that we can all solve together, gets larger. if everyone, can work at higher levels of abstraction, I, I think of it as like a kind of like a messy compiler that doesn't always do the right thing, right? Or you're like, I have an intention and you compile it into, machine code, but you're not always right. Which is, an exciting place to be. that we're in this world where we're getting to where I see the scope of the problems that we can create and tackle, becoming larger.

CJ: Totally. And com combining with the other tool, like the other LM tools. the other day I was, I. Just trying to do something with a bunch of unknowns where I wanted to make a video where the video was explaining a code snippet and I wanted all of it to be automated. And so I wanted to be able to just say my input is some code snippet and the output is a video that is animated and it brings in the code snippet. It explains what it does with a voiceover and it shows you like all this stuff. Basically, like my job as a developer graphic as right, and I was like, chat G B T, how would I build this? like how do I animate this and how would I animate some code showing up? And then it just like starts spitting out different like python blocks using map plot lib and using like these other animation libraries. And then I was like, okay, and now how do I like. describe this and it spits out the description that you take the description. It's okay, now go to some other tool. okay, now make this a voiceover. It gives you like the AI voiceover, and then you're able to ki it was like an hour of just playing around in a bunch of spaces that I had no idea about, what tools to use or, how to put things together. And just like between GitHub co-pilot. Helping write some of the code between chat, e p t, writing some of the code. It went from nothing to having a prototype in an hour because you can just whack at it in different ways. And even copying the error message directly into chat e p t. And it will just tell you like, here's the thing that you got wrong, and here's how to fix it. And it's been really fun. I don't know that style of development, like chat, G B t is the third like pair programmer in the room with you, has been interesting.

Alan: Yeah,

Colin: br brute forest development.

CJ: exactly.

Colin: Oh.

Alan: that's really exciting. just all of these tools and ways to develop are just really exciting cuz we're gonna get to see more stuff. we're gonna get to build things more easily. no, I'm really excited about building applications on top of all these things.

Colin: Absolutely. And I think, leverage is a great place to end this episode on. So thanks so much for joining us and spending time with us today, Alan. It's been awesome.

Alan: It's been a pleasure. Thanks for having me.

CJ: As always, you can head over to Build and learn.dev to check out all the links and resources. We'll drop those in the show notes for you. Thanks so much for listening. That's all, and we'll see you next time.

Colin: See ya.