Streamlining global ingress with ngrok

​
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.