Ep. #94, Elevating Review Environments with Colin Chartier of Webapp.io

Brian Douglas: Welcome to another installment of JAMstack Radio.

On the line, we've got Colin Chartier. Colin, how are you doing?

Colin Chartier: I'm well, Brian. Thanks for having me.

Brian: Perfect. So, you're here on the podcast.

We were introduced through a mutual connection, and here to talk about Webapp.io.

So, before we jump into that, I actually want to just find out, who is Colin? What are you doing, and how did you get here?

Colin: Well, I mean, I'm currently in startup life, of course.

I've been an executive at various startups for the past five years.

So, that, as you might expect, takes up most of my time.

Recreationally, I run sometimes. I've been learning to cook, as most other people during the pandemic. And I'm a recovering tap dancer.

Brian: Tap dancer? You can't just drop that in the middle of the bio. Did you do that in school, or growing up?

Colin: Yeah. I started when I was maybe eight and then I kept going through university.

Brian: That is quite the skillset, especially if you're an executive at a startup.

So, if you're doing your pitch deck, I imagine if you pull out the tap shoes, that is an automatic next round of funding right there.

Colin: My advice to everyone who asks how to race, just to channel your inner Fred Astaire.

Brian: We don't have to talk about tap dancing.

I actually want to talk about your history a little bit, about your startups and being executive.

So, were you at previous startups that maybe people have heard of?

Colin: I mean, I guess, potentially, certain niches.

I was CTO at a company called Price Hub, and they're probably a top five web scraping SaaS.

If you've ever had to scrape lots of things from the internet, you might have heard of Price Hub.

And I guess, right after Price Hub, I am now working at Webapp.io, which you might not have heard yet, but you will in time.

Brian: Well, I'm looking forward to learning more about that, so let's just jump in and find out.

I'll just ask the question. What is Webapp.io.

Colin: So, the idea for Web App is that CI is great and all, and if you're working on a full stack Web App and you're reviewing your coworkers' change, you can see the check marks in GitHub, but it's much easier just to play around with the website or make scripts that play around with the website on your behalf.

That's what we facilitate.

So, if you make a change, we'll spin up the environment with that change and let your coworkers look at it to tell you whether the change is good or not.

Brian: So, are we talking sandbox environments, so folks can just go and see this Web App live and sort of some pseudo stage environment?

Colin: Yeah. It's kind of halfway between Netlify and CircleCI, if that a makes sense.

So, there's a configuration file. Every time you push, it automatically gets created.

You don't have to deal with the cloud credentials or whatever. It's not a production environment.

You probably wouldn't send customers there, and it kind of acts like Heroku Dynos, where if you're not using them, they'll just sleep.

And then, when you request them, you'll see a spinner and then they'll wake up and you can play around with them.

Brian: And that sounds like a really interesting use case too as well, because if I'm on an engineering team, an organization, I want to have, I like having to Netlify Deploys to the site.

So, that way, I can go through and click through and see if things are still up and running, but you mentioned something interesting, where you see the "halfway point between CircleCI and Netlify," so what extras are you getting when reaching for a Webapp.io?

Colin: The big difference between us and something like Netlify is that we don't do production hosting, so we can be, I guess, sneakier with the build speeds.

So, in particular, we take memory snapshots of things as they build.

So, maybe the prototypic cool example is you start Postgres. You start your back end.

You start your front end and then you play around with the front end, interacting with the back end, interacting with the database and then you see if it works, kind of as a whole package.

And since we take memory snapshots, you don't have to do that whole process that takes 20 minutes every time.

You just push. It loads a snapshot of the database and backend, copies in your new front end changes and then gives you a link, and you can immediately start running with a new copy of the database, and with potentially the migrations or the backend branch you're working on or whatever.

Brian: That's intriguing.

So, setting up local environments with development databases is something that folks do and set up and sort of set it and forget it, but to recreate that in a--

I don't know if I'm using the right term for a "sandbox environment."

So, a Webapp.io, it sounds like y'all set that up through some YAML upfront?

Colin: Yeah. I mean, I guess I personally didn't like YAML when I was first picking out the MVP, so I think less CircleCI, not YAML, more Docker File .

Brian: Got it.

Colin: So, you just have the steps top down.

It snapshots things automatically as it builds and then it figures out what step it can skip to the next time you push, so you don't have to micromanage the cash keys or whatever you'd usually have to do.

Brian: Got it. That's what you were talking about, the memory snapshots.

So, is this across team?

So, if I open up a PR and I've got it working and it's got the sort of all the staging data and everything like that, and people now can go test it, my teammate now has access to that same staging data if they were to go to click that link?

Colin: Yeah. So, it's just, again, pretty similar to Netlify. You have internet visible links.

They're just embedded directly in the pull request.

We actually embed a screenshot of the landing page for your specific change.

People click the screenshot and it just sends them to the internet visible per commit environment.

Brian: I love it.

Colin: And then if you break it, you can just rebuild it.

There's no customer screening if you break the staging base or run a bad migration or something.

Brian: And I mean, so now my brains are sort of rolling through all these use cases.

"How be doing this day to day?" I know, whenever I go to squash a bug, there's a very specific use case of how this sort of happened in production.

And I need to reproduce that and then convince the rest of the team that I've solved the problem.

So, are you saying that if I set up a snapshot, leveraging the data that is necessary, that the showcase that I solved this problem, are folks able to like go in there and sort of see how I basically-- I'm thinking of when you show houses.

You're staging up the house, and people can walk through and see, "Wow, I didn't know you could put a TV over the fireplace," which now everybody does.

Now you get to go and see, "TV over the fireplace, that was what was broken before. Let's just now hyper focus on clicking in the environment and make sure that works. I'm able to stage the setup in that way?

Colin: Yeah. A super common thing that--

We didn't even think of this when we were first making the technology, but I guess it kind of evolved alongside it--

Is you can take a snapshot, a database dump, of a production database and then you can anonymize it.

So, just make a script that goes through all the rows, swaps out the names with fake names and then you get this thing that looks like production that's GDPR compliant.

Brian: Nice.

Colin: And then you just throw that in a bucket and then, for your build script, you can say, "Start the database. Download this dump, which might take five minutes. Load the dump, which might take 10 minutes. And then take a memory snapshot of it."

And then the next time you push, you get another copy of that CTA database, and you can even test things like, "Does the migration I just make actually work against production data, or does that violate some foreign keys or something," because it, you could load the database snapshot and then you run the differential things for your specific change.

Brian: That's extremely powerful.

Just the one script of you saying that you could take a snapshot, replace the names to make it GDPR compliant and then have that reusable for future and more instances of being able to test data is extremely powerful.

Because right now I'm working on a problem for my side project, which is Open Sauce , and I am seeding the data with actual real live data, which is GitHub data to GitHub repos, and I have definitely wiped out the database multiple times while testing this.

And it would be so much easier if I could just grab a bunch of random projects and then test to see if the interaction of my project works, something that's close to production.

You're basically just solving a bunch of steps in my day to day workflow, which is pretty awesome.

I wanted to actually touch on something that I saw on your website, too, as well.

It's a pretty bold thing to put on the website, which is, "Review your code like Facebook does."

Can we get into what that means, and what's the history of that tagline?

Colin: Sure.

So, I mean, I guess most developers probably know that the fangs, in particular, Facebook and Google, have just these huge teams of specifically developer engineers that all they do is make developer tooling for the rest of the developers, because I think Google has 100,000 developers now.

So, from Google's perspective, it makes sense to put 1,000 developers working on developer tools so that when you push and you open up pull requests, if it's one percent faster for 100,000 developers to merge their pull requests, then it's a big win for Google, because it's the equivalent of hiring hundreds of people.

So, the big fangs have figured out a lot of these things, the snapshotting, the loading database snapshots, making ephemeral environments, pull request automation in general, really, really good comprehensive tests that tell you exactly what line number you caused a bug on, things like that.

But, if you're working at basically any other company, then a fang, you don't get all those things.

You get some glimpse of it with GitHub Marketplace or with GitHub Actions or with these configurable tools, but you still eventually need to hire someone to set up all of these pipelines, and you basically never get as good of an experience as Facebook gives you.

So, we're hoping, longterm, to let everyone have that experience of, "You push something. It's broken. Your coder viewer can tell you exactly how it's broken, on what lines, and you can get it shown to customers the same day you made the change instead of a week and a half later when you finally get the last reviewer to look at it."

Brian: So, my day job being GitHub, I've definitely seen the evolution of us get to a point where we have this sort of behemoth of a dev ops pipeline to just get something out the door, or just reviewed and test in provision things, and there's a whole team that does a bunch of stuff.

I don't know what they're doing, but they make it easier for me to get my one off DevRel application up in production.

And I definitely see a trend of folks coming off of fang companies and then recreating startups or one-off tools or open source projects to solve problems.

So, I'm curious, you and your co-founders, y'all have that experience coming from fang companies, or I guess my real question is, where would this inspiration come from, to solve this problem?

Colin: Sure.

So, the specific problem of needing snapshots of your database and wanting to make snapshots of your environment to run tests against, in particular, browser automation, and have preview links was from my experience at my last...

Being CTO of a SaaS company, you have the same sorts of goals that Google does.

I've hired 10 engineers. I want all of my engineers to be 10% faster so that I don't have to hire more people to get more output.

So, I was solving a lot of these things kind of on the back end, and I was looking at all the cutting edge.

The fangs all make papers to you exemplify how good it is to work there or whatever.

You have the engineering blogs. You have the, you know.

"This how we take memory snapshots of Kubernetes clusters, and here's how we restore, or here's how we forked Postgress to--"

Brian: This is the one reason why I went to OSCON and all the O'Reilly Conferences previously, which RIP.

They don't exist anymore, but could you get all the fang employees to talk about out how there are big, hairy issues?

I guess one of the most popular ones is, which is not route related to this, but the Chaos Monkey and Netflix.

The amount of people who tried to recreate that at their own companies out there, watching the one talk years ago, and now entire startups are built on that same idea, absolutely amazing.

So, it makes tons of sense.

Colin: So, I mean, when I had that experience, my co-founder didn't work as a programmer, but she worked at various tech companies, and I guess she worked on the other side where she was asking people to get features made so that marketing could launch something, and the developers would take three weeks to even get a fresh feature with no users to the point that it could be shown to the users to gather feedback.

It would take three weeks at a "fast moving tech company."

So, she was really on board with the vision of, "Build something. Show it to users as quickly as possible, because you know it's not broken and then iterate from there."

Brian: That's amazing, because I, just before this call, I was pairing with one of my coworkers on a problem where it, basically, essentially, the age old problem, it works on my machine, literally, but I could not get it to work on their machine.

And we went through all of the lists of the things, tried to figure out what's happening, and kind of summarize it all to permissions inside the repository we were trying to access data from.

It's a GitHub problem we were working on, so we just use repos as test databases.

And we're now in our third week pairing on this thing, because it's not a high priority problem.

It's just a side project, and it came to the third week.

We finally figured out, "Permissions, I have permissions you don't have. We should probably fix that."

And based on the error message and everything like that, we didn't quite understand what was happening up until very recently, but even having just environments with the same test users, and to be able to have that consistent...

For example, in Google Chrome, because I did a lot of Web App development, the dropdown to create different profiles in Chrome, so that way, you can have different accounts for the same thing you're testing, that is annoying, which is not a service that you take care of.

Google, I think, sort of takes care of that natively, but in the browser, but just having extra user accounts to test is quite annoying to set up every time I want to test a feature.

Colin: Funny you should mention that, but I'm sure most people at this point have heard of Browser Stack or Percy or Cypress.

There's a bunch of these browser automation frameworks that have popped up since, I want to say, 2015, where, once you could do Headless Chrome, everyone wanted to put Chrome in a Docker container and then try to log in and make sure that logins still worked, but I think it's really evolved into making sure that it also works on Linux Firefox and iOS Safari and Chrome on Windows.

So, these permutations of browsers, people want to try them on every pull request, and they can sort of do that for front end stuff with Netlify or Vercel or their own PR bot or whatever, but it's really difficult to spin up an environment for a pull request to the point that you can actually do browser automation.

Does the dropdown work on all 10 combinations of browsers that we want to support?

So, that's another thing our users have been using the environments for, because you make one.

You do the database. You start the backend.

You start the front end and then we have a split directive, so you can make 10 copies of it, and each of the 10 copies, you can test a different permutation of browser and operating system with Browser Stack or something like that.

You can use your existing tool, but you just magically get an environment to run it in.

Brian: Now I'm just thinking up another example that I did with Playwright. I guess Playwright is more than just Chrome.

It also does Edge and Firefox as well, but testing to makes sure stuff is rendering, because how many times I've definitely had a Safari bug, or something even in Firefox or Brave, because everybody has got their own on top of Chromium.

Well, Safari is not Chromium, but you know what I mean.

Basically, everybody has got their own skin in how things work that you don't know until you open up something that's not Chrome and see, "Wow. We definitely did not make this feature correctly."

Colin: Even us as a startup, we don't necessarily do as much browser testing as we should because you don't have the cycles to set up all of the different harnesses, but we do have a test that just clicks every page.

It basically loads the landing page, finds all the links on the landing page, clicks them all and then it just makes a tree of all of the visitable links on the webpage, from the main landing page.

So, it clicks the dashboard, and from dashboard, it clicks all the tabs, and from all the tabs, it clicks everything, and it's basically a 50 line Cypress file.

It's super simple, but all it does is it makes sure there's no 404s in any of the pages and there's no browser errors, and I think that's caught more bugs than almost any other test, probably all the other tests combined, because most front end bugs end up being, "You broke the compilation on the account page and now no one would've been able to log in."

Brian: And it's something that you would kind of want to know.

When the login is broken, you need to know that at the time of PR rather than when it goes up in production.

So, you mentioned Cyprus, too, a couple times. I'm curious.

How do you interact with Web App? How do you get started? What are the sort of steps?

If I have a project, what am I looking for to get started to work with it?

Colin: I mean, if you've ever set up CI on a project, it's very similar.

If you think about setting up a build process, you'd have your configuration to, "These are the steps they need to do to build."

You'd have your Docker File or whatever, to specify how to build the image. And then, when you push, you'd install it onto your GitHub repository and then every time you push, it would run. Ours is only two steps. So, it's even simpler than that method, because we combine the YAML with the Docker File. So, all you need to do is install us around the GitHub Marketplace.

I think we're top 10 CI plugins, I want to say.

So, you install it on your GitHub repository.

You create a file named Layer File that just contains the directives and then we do all the memory snapshotting magically.

One of the directives is Exposed Website. So, it's like a Docker File but we've extended it to have extra things.

So, if you want just an ephemeral environment, you make a Layer File that's like, Install Docker Compose. Run Docker Compose, UpDash, Exposed Website, Local Host 3,000, and then that's it.

Every time you push from then on, you get a link in your pull requests to view that environment.

Brian: Excellent. I'm definitely going to be checking this out.

You mentioned the marketplace. I've definitely got projects.

We just found your one simple example of finding broken links.

I just had accepted a PR on one of my projects, my doc site, actually, because I had a of couple broken links because we moved stuff around, and you try to catch all that stuff when you're reviewing PRs, but it always is going to be the case where just something that just gets--

It slips through. So, Colin, I appreciate you coming and chatting about that.

Anything else you want to cover about Webapp.io that maybe we didn't get a chance to touch on?

Colin: I mean, the only, I guess, remaining thing is broadly what dev ops means for people building Web Apps in general, because I guess the question I get most often is, "Can I use this with GitHub Actions, or am I going to have to migrate all of my GitHub Actions, build process, over to this?"

And I think, in general, you should just choose tools that allow you to put your existing process in.

If you had to switch all of your build process every time you changed cloud providers or changed SCMs or changed from organization to individual repository, you just spend all of your time migrating things.

So, the whole thesis of Web App is that you can put it alongside your existing stuff.

It shows up as an extra check below your GitHub Actions, below your CircleCI, below your Browser Stack, your Percy.

And then, if you do want to migrate things into it, it's possible, but it's not required.

Brian: It's nice to hear that flexibility, too, as well, and for folks who just want to tinker was stuff--

Because I know back, you mentioned, four or five years ago, it seemed like with all these cloud providers, it was, "You choose one and that's it."

And I know, sitting at Netlify as an early employee, we figured out the multi-cloud environments pretty quickly after you run through all the sort of free credits.

And I love the fact that, even with that, that you're able to pick and choose what you'd like to use as your provider, and despite vendor lock-in, there's always workarounds, and I prefer the workarounds.

Or just folks providing opportunity to try different providers upfront, because it seems kind of slimy, getting stuck in the one provider.

Colin: Our production is a big Kubernetes cluster.

It's actually a bare metal Kubernetes cluster, which no one ever advises, because the people advising you are the ones that the want you to use their cloud, of course, but we had a point.

The main servers we use have, I think, 800 gigabytes of RAM, and they're $1,000 a month-ish, which is already a pretty good deal, because cloud providers would be three or four times that.

We use a European provider called OVH for the main kind of powerful servers to do the builds.

But our provider ran out of servers in April.

Because of the chip shortage in the supply chain, we were trying to get servers in April, and they said it was impossible for us to get more servers for the next 60 days or something, and we had customers that were onboarding, so we couldn't wait 60 days.

So, I added servers from another provider and just glued them into the existing Kubernetes cluster, because I guess that's one of the big benefits of using Kubernetes is you can span it across multiple clouds. So, I guess, very similar to your experience at Netlify, where if you don't vendor lock yourself too hard, it's possible to circumvent unexpected issues with your cloud providers.

Brian: Amazing. So, again, thanks for the conversation. I did want to transition us, but thanks.

Folks, if you're listening and this all resonated with you.

It sounds like these are some easy intros for you to try Webapp.i o in some of your projects, so definitely check it out.

In the show notes, we'll have a link to the website, Web App I0, which is literally the website, but also Colin and his Twitter account as well, to reach out, ask questions and report back.

Tell us if you like it, but now what I want to talk about is what I like, which is Picks.

These are Jam Picks, things that we're jamming on. This could be movie, food, tech related.

There's not really a limitation. We've got kind of, really, the extensive list of previous picks and some really profound ones in the past.

But, if you don't mind, I'll go first. And the one and pick that's kind of where I've taken up a lot of my time--

For whatever reason, I've just got a lot of free time to watch YouTube--

Is actually Tesla's. I don't own a Tesla today, but I've done crazy amount of research on it.

I think sort of the buzz of what is happening at Tesla and these cars in general are just--

And it continues to be up and to the right. Do you drive a Tesla, Colin?

Colin: I do not.

Brian: Do not? Well, you're going to get out of the bandwagon soon.

So, what I did is I actually did a test drive at Tesla.

This is my pick, is test driving Teslas in San Francisco, which I would pay for this experience, because if you know San Francisco, there're tons of Hills everywhere, doesn't matter if you're downtown.

You're a minute away from a hill.

I had an afternoon with no meetings , and I'm like, I'm going to sign up to test drive at Tesla, went into San Francisco, got into a Tesla, at Model Y, which is absolutely a gorgeous, amazing car.

It's not quite the X, but it's still a very nice crossover, and they give you 45 minutes, with you in a Tesla, to be able to test drive all over San Francisco, and San Francisco, most people might not know this, is seven square miles.

So, you can go all around San Francisco twice in 45 minutes.

That's what I did. I went up the Hills.

I almost went down Lumbard Street, which was the curvy street or what whatnot.

It's the famous street, but even during the pandemic, that's known to be backed up with the tourists who just want to drive down there.

So, I was like, "That would be my whole time, just waiting to go down the street."

It would be an amazing experience in a Tesla, to be quite honest, but I'll probably do it again.

I'll probably go down. That'll be my goal, to go down that street, but I was actually really impressed.

If anybody's never looked into Tesla, I don't own stock in Tesla or anything like that.

I just, one day, was like, "Hey, I should look into this, because everybody raves about Teslas," and now I'll be buying a Tesla.

It's on pre-order for six months, because chip shortages and all that other stuff. So, I'm looking forward to it.

Colin: Here in Canada, you've started seeing Teslas.

It's certainly less prevalent than the Bay, but I think, in the past, I want to say, two years, you've started seeing more and more, to the point that maybe once a day, I'll see a Tesla.

Brian: They're everywhere.

Colin: I think, as the number goes up, hopefully, there'll be more chargers.

That's the big problem here is that most garages don't have chargers and it's already hard to get parking in downtown Toronto.

Brian: That is a challenge.

I do benefit, being in the Bay Area, there's chargers, quite a few chargers in the area.

And then Tesla is trying to do this whole thing with the solar panels on the roof and then the superchargers at the home.

So, there's a lot of benefit, but I think Tesla, just recently, they're moving headquarters to Texas now.

They're still going to be in the Bay Area, but I think you're going to see an expanse, across the US at least.

I can't speak for Canada, but we'll see.

Colin: Have you tried driving in the Waymp in Austin yet?

Brian: I haven't. That's a thing?

Colin: Yeah. I guess Waymo has been doing driverless car tests.

There's the driverless taxi that you can drive around with.

Brian: Got it.

Colin: I think test drive a Tesla and drive a Waymo are the two car experiences.

Brian: Excellent. I vaguely remember this actually being a thing, but I've not tried that out, but I'm going to put it on my list, because I checked off the box for the Tesla.

Now I've got to Waymo.

Colin: I guess, once you get your Tesla, you have to practice, and you can go to Las Vegas, go a little further.

Brian: Exactly. Cool. Do you have any picks to share with the audience?

Colin: I recently got an espresso maker. That's called a Breville Bambino.

It's a single shot espresso maker, and it has this little steam nozzle that you can use to foam milk, but I bought it just because I like espresso, and I guess I was kind of tired of drip coffee and I wanted some slightly more interesting coffee in the mornings, but I realized that, because it has this nozzle that comes off of the right side, it has hot water for Americanos and it has steam for steaming milk.

You can actually make all sorts of things. You can make bowl noodles.

You can make tea. I have a teapot, and you just put loose leaf tea in the teapots like a basket and then you aim the hot water jet at it, and you just turn the hot water on.

And it automatically turns off after a cup or two, so you can just press the hot water button and leave and you come back with a cup of tea versus having to boil the water, or microwaving the cup.

It's a whole thing, and it's always exactly 90 degrees, so it's perfect for most tea.

Brian: That is amazing.

And I've definitely seen quite a few people pick up fancier coffee setups, especially being home.

I lucked out there. In the entire pandemic, I lived across the street from a coffee shop, so I would just peek out the window and see if there was a line out the door, and if there wasn't, that was my life hack for coffee.

Well, I appreciate you chatting with miss.

I am actually going to look up this Bambino coffee machine, espresso machine, rather, and I'm also going to check out Web App, because I think I've got a use case for this as well at work.

So, with that being said, Colin, thanks so much for the conversation.

Listeners, check out everything we talked about and keep spreading the Jam.