Jerod Santo: So Ilya, this sounds really cool, how you’re talking about collocating the data and the edge functions. One of the things that I keep saying over and over again - and I spoke with Evan Weaver from Fauna on this - generalizing that problem of “We have our functions running at these edge CDNs, and yet our data is not collocated.” That seems like a problem that lots of people are working on. It sounds like with Oxygen, at least in the context of your Shopify, y’all are solving that for everybody. Now, generic solutions for your random web apps is not out there, but in the case of Shopify, you’re collocating that and making that server-side really fast.

Shawn Wang: Fauna, exactly. And that’s because people know how to pay for storage.

Jerod Santo: Right? That does sound pretty awesome. So I’ve kind of just been saying “Well, who’s gonna–” And then there’s like “Well, FaunaDB is doing that”, and I think Cockroach has some angle into that… There’s people working on this. Mostly, what people say is like “Well, it’s being worked on.” So everybody kind of wants that, because once your database servers are just CDN, then of course your application servers can just be that way as well, if you have a separate [unintelligible 01:15:12.02] But in the case of an embedded database, well your application is already out there, and your database is embedded, and Litestream is just managing that.

So it sounds really rad… But they’re read-only replicas, so when it comes to writes, you’d still have a centralized thing, but writes are usually less often than reads… So it’s not the panacea, but it’s pretty stinkin’ close if it could work well.

Paul Dix: Right, exactly. Their hope was that they would get this massively popular project - which it is; Elastic is a top ten database project, used the world over… But then they want – like, the classic strategy is you spend a bunch of money to get optimized growth, and then once you have scale and a monopoly, you want to start collecting monopoly rents. Now Elastic can’t collect monopoly rents because other people are hosting Elastic, so they’re trying to change the model so that they can do that… But the problem is then you’re a different sort of business entirely. Like, it’s fine to be a closed source database company; there’s Fauna which is new, Firebase is closed source… Each of the cloud providers has a handful of closed source databases. So that’s a totally fine thing to do. But to try and say like “Oh, we’re open source” and then change it - it’s kind of ridiculous.

Brandon Bayer: Sure. So Prisma 2 is an opinion that we have by default, but we don’t depend on that. You can rip that out, you can use a type of ORM, or anything else. Fauna… We’ll be adding plugins for things like Fauna. And actually, Prisma will be a plugin, too. So database-agnostic, but Prisma 2 as a default.

Another opinion is whenever you generate a new app, you have things already configured for you, like Prettier, ESLint, Husky Git hooks - all of the stuff most people have… But you can easily change that. We don’t abstract any of that away. You still have full control over it.

Guillermo Rauch: And there is another problem with that, by the way, which is the latency problem that I was describing with the Stripe example. With the exception of Fauna’s geo-replication model, which is built on a novel replication and coordination system called Calvin. With the exception of that, and perhaps Google Spanner, databases are not mature enough yet to co-exist with your edge.

Divya Sasidharan: Yeah, I think it’s interesting, because whenever you talk about a JAMstack solution - and this comes up a lot whenever I talk to people, because I work at Netlify on the developer experience team - generally it’s like “Okay, I work with a JAMstack. I have something that’s prerendered, a static application that works”, and then the moment the database part comes in, it’s like the next hurdle, because provisioning it takes a while… And I think we’ve worked a lot on trying to make that a bit smoother, so I think currently we have – within the CLI you can provision a Fauna database, so that it works with Netlify…

But again, we’re trying to smooth out the curves of that, because there is some – it’s essentially moving from Netlify to Fauna, it’s a lot of the back and forth… And looking at the RedwoodJS docs, there is this mention of not wanting to do that. Because the moment you talk about a database, you’re like “Oh, I have to spin it up somewhere else, and then I have to go to this other dashboard.” And now I have two things. I have the Netlify dashboard, which holds my static application, and then the database - whatever; if I’m using Firebase, or Fauna, or whatever that is, I have to go there. So there’s two places. And I think that adds a cognitive burden, because now you’re just like “There’s two places that things live in which my deployed app needs to function…”

I think the nice thing about RedwoodJS is just the ability for you to have everything all in one. And I think within Netlify as well we think a lot about how to make people be incredibly productive without having to make those cognitive leaps, or move into a separate dashboard to do things that they want to do.

Brian Leroux: Oh, boy… Well, I think data gravity is an interesting thing to talk about and think about. A lot of people are getting really excited about GraphQL, and rightfully, because it’s unlocking databases for the front-end. And there really hasn’t been a breakout new way to understand or do this. I think Fauna is kind of interesting; I’m personally a huge fan of DynamoDB… But where our data is and being able to get our data fast remains a massively unsolved problem. And who owns that data, and how do we access it from multiple places - because it’s not just a website probably accessing it; you might need to ad-hoc query it for the business guy, or you might need to replicate it.

So I think the big, new interesting thing is gonna be “How do we deal with all these data sources? Where do those data sources live? How do we interact with them?” Because there’s no clear standards here. I think everyone can agree we don’t like trying to scale MySQL shards… [laughs]

Tammer Saleh: There’s a variety of tools for deploying Kubernetes to bare metal installations. And that’s not really the hard part with Kubernetes. In the cloud, there’s managed Kubernetes, and that solves all your problems. That’s not the problem with Kubernetes in complexity. In fact, getting a Kubernetes cluster up and running is fairly easy. On bare metal, you have some issues with the networking, but there’s projects to solve there. You’ve got kube-router, and you’ve got MetalLB, and you’ve got others that solve that problem for you.

[15:56] It’s interesting that you brought up BOSH and Cloud Foundry. For those who don’t know, the way that Cloud Foundry was designed was that we had two different products. We had BOSH, which was sort of a competitor to Terraform and Ansible and Salt. I don’t know this for sure, but I think it came right out of the Google’s Borg. It’s like a rewrite of Borg, basically. And it’s very difficult to use. But once you use it, once you learn it, Stockholm Syndrome kicks in and you start to love it. There’s huge BOSH fanatics, right? And BOSH was the tool that the operator used to deploy Cloud Foundry; very difficult to use, but very powerful. And Cloud Foundry was the interface that the operator then could present to the application developers, which was basically a blatant rip-off of Heroku, which was a great model. Twelve-factor buildpacks, all that stuff made it really easy for application developers. But here’s the interesting thing - I refer to that as the great wall DevOps model where Cloud Foundry allowed the operator to serve the application developer well by giving the operator this beautiful wall that both sides really appreciated. The operator appreciated how easy it was to manage Cloud Foundry through BOSH, and the application developer appreciated how powerful it was for them to manage their application through Cloud Foundry.

Kubernetes is entirely different from that, right? Kubernetes is what I call the kumbaya DevOps model where everybody has to know everything, right? Kubernetes doesn’t have the concept of an operator, versus an application developer. At best, it gives you some tools where you can kind of build that using rbacks and stuff, but that’s really difficult to do. And nobody knows quite where the line is supposed to be. Yeah, so everybody does it differently, you know?

Jerod Santo: Because hearing that from Mislav, from a Git fanatic and expert… And he even admits in the post, he’s known the CLI for all these years, and even though it’s intuitive now, many of us, we just memorized the magic incantations; “Yes, I can delete a remote branch from the CLI.” I had no idea why I have to push with a colon in front of the branch name, or whatever it is… That despite how powerful the technology is, and how useful it is, and how much it’s enabled, it’s just too hard to learn. And his big thrust of that post is that whatever comes next needs to be more human-oriented, and not computer-oriented. Pretty fascinating stuff coming from Mislav.

Jerod Santo: Okay. I never said I was a testing fanatic, I was just telling you that I am pro testing.

Adam Argyle: Yeah, cool. I’ve just been building apps in this industry for a long time. I was hacking on websites before Flash and Flex came around, and I jumped on that bandwagon. I was building all these big, robust Swifts with robot legs and MVC patterns back in the day, and I got pumped on Swift’s native platform, so I was pushing Flash apps onto your iPhone… They were not very good, but I was doing it anyway. [laughter] And I’m just a web fanatic, so I happily pivoted into the web, and I’ve been kind of going along with everybody else. I wrote a bunch of jQuery stuff; I still like jQuery. I wrote a bunch of Backbone; I’ll write Angular 1, I’ll write Angular Infinity, I’ll write React - I don’t care. And that’s kind of why the tools I build are as web components. If you ask me what I wanna use, I wanna use the least amount possible.

[00:04:15.04] So yeah, I’m a UX engineer on Google Cloud. That’s kind of a cool role. It’s probably worth a whole other conversation about what that even means… But here’s a little secret - this demo and this tool I built has kind of becoming a dev realm on Chrome. So you’re probably not too surprised, as I’m an outgoing weirdo that’s passionate about the web, and I’ll be focusing on UI and CSS, so I’ll be the first person that’s like “CSS is cool! Hey, let’s build stuff with CSS! Watch me move boxes around.” Y’all think boxes are hard to move, and I’m like “No, they’re fun!” So that’s kind of where it’s going, where I’ve been in a decent amount of short time. That’s pretty good, I think.

Adam Stacoviak: Cool, man. We’ll have to get you slotted on Go Time too, since you’re such a Go fanatic. You have to listen - GoTime.fm.

Pieter Hintjens: And I was doing this workshop with a bunch of people from Samsung, it was our first workshop there. We were trying this kind of prototype distributed system, and it was what eventually became Zyre, I guess. They’d been trying to do this for some time and they kept failing, trying different ways to do it. So they had five or six of these really clever guys - there was one from Kazakhstan, there was a bunch of Americans, there was one from… I don’t know, it was a very diverse mix of people brought in for this. And after three or four days we had built really amazing stuff and it was all working; little video games working across four mobile phones, and everybody was very impressed. Then just very randomly, I was like “There’s got to be a gun range somewhere”, and it turned out that the whole class were gun fanatics, shooting fanatics, in one way or another. There were maybe one or two who had never shot, but who are into it and willing to try it.

So we found a range, went there and shot. I was like “Okay, I love Dallas.” [laughs] It was cheap, it was easy, they were friendly, the guns were great, I was able to shoot. Over that year I must have gone shooting a hundred times. I would just shoot 200-300 rounds of ammunition. And I got really good at it; it’s just a matter of practice.

Then I decided at a certain point - this was a kind of an insane project; we all went kind of batshit crazy in this project for different reasons. It was incredibly political. We had been trying to do stuff that everybody wanted to do, and when we had got some success they were trying to kill us and take it over from us, both people from inside the company and outside the company. It was just endless, endless politics, so my job was to navigate that politics and just beat off all the bullies and keep the team together, alive and fed. So at a certain point I’m like “Okay, I’m gonna get my pistol instructor badge.” I become an NRA member…