Snaplet with Peter Pistorius

Episode Description

Peter Pistorius discusses his journey from co-creating RedwoodJS to building Snaplet, a tool that copies and transforms production databases for safe local development.

Episode Summary

Peter Pistorius, co-creator of RedwoodJS, returns to discuss his transition from framework development to building Snaplet, a developer tool that addresses a persistent pain point: accessing realistic data during development. The conversation begins with Peter reflecting on his time building Redwood, his philosophy of writing simple, readable code (which he humorously calls "dumbass driven development"), and how he's shifted from active contributor to community member. The focus then moves to Snaplet, which copies production databases, strips out personally identifiable information through configurable transformations, and restores sanitized snapshots to local or cloud development environments. Christopher, a beta user, shares practical use cases including testing database migrations safely and working with realistic pagination data. The discussion broadens into how developers have historically suffered from "learned helplessness" around database tooling, relying on brittle seed files instead of demanding better workflows. Peter walks through Snaplet's roadmap, including JavaScript callback transformations with TypeScript support, database subsetting, data generation to replace seed files, and real-time read-only proxies. The hosts explore adjacent topics like coding in the cloud with GitHub Codespaces and Gitpod, the Postgres-versus-MySQL debate, the rise of SWC as a transpilation tool, and the emerging framework landscape including Remix and Astro. Peter closes by speculating that JavaScript frameworks may converge around lighter runtimes like Cloudflare Workers rather than Node.js.

Chapters

00:00:00 - Peter's Redwood Journey and Coding Philosophy

Peter Pistorius returns to the podcast and reflects on what building RedwoodJS meant for his career, describing it as a rare creative opportunity alongside talented collaborators. Now focused on his startup, he's stepped back from active code contributions but remains engaged with the community through Slack and PR reviews.

The conversation turns to Peter's approach to writing code and documentation. He shares an anecdote about coining "dumbass driven development" during a job interview in Oklahoma, a philosophy centered on writing code simple enough for his future self to understand. This readability-first mindset carried over to Redwood, where new contributors frequently remark on how approachable the codebase is despite the framework's complexity. The hosts also discuss Tom Preston-Werner's Readme Driven Development methodology and the importance of engineers being good explainers.

00:05:33 - Introducing Snaplet and the Problem It Solves

Peter explains how he transitioned from full-time Redwood contributor to startup founder, handing off the framework to the community. The discussion shifts to Snaplet's core purpose: giving developers access to realistic production data without exposing private information. Peter frames the problem around how developers have great tooling for code but poor tooling for the data their code runs against.

Christopher shares his experience as a long-time beta user, highlighting how Snaplet transformed his workflow around database migrations. Rather than running untested migrations against production for the first time, developers can pull a sanitized copy, iterate on their migrations locally, and verify everything works before deploying. The conversation also covers the inadequacy of seed files, which quickly become outdated as schemas evolve, and how Snaplet eliminates the need to constantly maintain them.

00:13:22 - Learned Helplessness and Developer Self-Service

Peter introduces the concept of "learned helplessness" in developer workflows, borrowed from his Redwood days with Tom Preston-Werner and Rob Cameron. Developers tend to accept painful processes like maintaining seed files simply because that's how things have always been done. Snaplet challenges this by asking why developers shouldn't code against actual production data in development environments.

The discussion expands into the broader theme of developer self-service versus relying on dedicated database or DevOps teams. Peter argues that in distributed teams, waiting weeks for someone else to provision data is unacceptable. He draws parallels to how DevOps evolved to empower developers with infrastructure tooling, and suggests that database workflows need a similar transformation so developers can independently manage their own data needs.

00:19:21 - DevOps Evolution and Database Tooling Landscape

Christopher asks whether improved developer tooling will shrink the DevOps role, and Peter offers a nuanced view: site reliability engineers and DevOps people serve overlapping but distinct functions, and bringing those worlds closer together increases developer productivity. The conversation shifts to how modern tools like Prisma, Supabase, and PlanetScale are making databases more accessible to developers who previously treated them as black boxes.

The hosts discuss the Postgres-versus-MySQL debate, with Peter noting that for most developers using an ORM like Prisma, the underlying database engine is essentially an implementation detail. Anthony points out that Prisma handles the translation layer, making the choice less consequential. The group agrees that serverless database models are abstracting away concerns about storage engines, replication, and distribution, much like developers rarely think about which Linux distribution their servers run.

00:26:24 - Snaplet's Technical Roadmap and Workflow Design

Peter details Snaplet's upcoming features, including JavaScript callback functions with TypeScript support for data transformations, replacing the existing DSL approach. The integration of Monaco editor into the web interface gives developers type-aware editing that understands column constraints like nullability. This is especially valuable for transforming JSON data stored in database columns, where SQL-based approaches are cumbersome.

Christopher and Peter discuss the balance between web-based dashboards and CLI workflows, with Peter emphasizing that transformation configurations should ultimately live in repositories as versioned artifacts reviewable in pull requests. The conversation touches on GitHub Actions integration for automated PII compliance checks and the vision of database-per-PR workflows, similar to what PlanetScale already offers with database branching for preview environments.

00:33:11 - Hiring, Cloud Development, and Snaplet's Origin Story

Peter shares what Snaplet is looking for in new hires: JavaScript and TypeScript developers who are passionate about developer experience around data, noting that deep database knowledge isn't required. He outlines exciting technical challenges including Postgres wire protocols, in-memory databases, and memory-efficient concurrent transformations. The conversation then moves to coding in the cloud with GitHub Codespaces and Gitpod.

Peter reveals Snaplet's origin story: after leaving Shutterbug and returning to a 2013 MacBook Pro, slow compile times drove him to cloud-based development, where he discovered that provisioning data was the missing piece. Every other aspect of a development environment could be reproduced, but realistic database content required manual, time-consuming dump-and-restore processes. This gap inspired Snaplet's core workflow of automated, privacy-safe database snapshots that can be restored anywhere.

00:41:13 - SWC, Astro, Remix, and the Future of Frameworks

The final segment covers the broader JavaScript ecosystem. Peter shares his experience testing SWC for both Redwood and Snaplet, noting it's nearly production-ready but still lacks features like import aliases and JavaScript-based plugin authoring. Anthony introduces Peter to Astro's multi-framework partial hydration approach and the emerging islands architecture pattern.

The discussion turns to Remix's launch and community speculation about whether it might converge with Next.js. Anthony argues they serve overlapping concerns but have different ambitions, with Remix positioning itself more as a Rails-like full-stack framework. Peter offers a forward-looking take: rather than frameworks merging, they may converge on targeting lighter runtimes like Cloudflare Workers and V8 isolates instead of Node.js, using web-standard APIs like the Fetch standard as a common foundation. The episode closes with thanks to Peter and plans for a future retrospective when Redwood reaches version 1.0.

Transcript

00:00:00 - Christopher Burns

I met a few Florida people at a Burger King and a 7-Eleven. As a British person, you're just like, I've just come here to get some bread, please.

00:00:19 - Anthony Campolo

Peter Pistorius, welcome to the show.

00:00:21 - Peter Pistorius

Thank you. This is my second time around, and hopefully this time it's going to be successful. I even got a fancy microphone for it.

00:00:28 - Anthony Campolo

Awesome. Yeah, I was actually listening back. We still have the first recording that we did. I think it might be cool to release it as a bonus episode, because it is a great conversation. We just had a couple of audio issues. But for people who don't know you, you are the co-creator of Redwood, along with Tom Preston-Werner.

I've always told people that you are the Rosetta Stone to Redwood. If you really want to understand the history of Redwood and what Redwood is, and why it works the way it does, you really have to understand Peter, because Peter wrote a whole lot of the code. At this point, it's become this whole big project all these other people are contributing to. So I'd be curious, what is your perspective now on Redwood, having gone through this whole journey with it?

00:01:09 - Peter Pistorius

I think Redwood was, for me personally, one of the most important things I've done in my career. Having the option to build a framework and pour your creativity into it, along with a set of great people alongside you, supporting you and coming up with great ideas, is a rare opportunity. I have a great sense of ownership for the framework.

Now that I'm building my startup Snaplet, I had to distance myself from that ownership. It's tough, but it's nice to see people contributing without me, without my support, without me explaining everything to them. It makes me feel like I left the code in a good place, and not just me. Obviously, all the other contributors as well.

00:01:47 - Anthony Campolo

And not just the code, but the docs and the videos and everything that goes along with actually learning a framework.

00:01:52 - Peter Pistorius

Yeah, and to be honest, I am probably the worst at docs. I didn't write as many as I should have, and that was mostly other people, so that's all on them.

00:02:02 - Anthony Campolo

But what I like is that you do write whenever you write, like press and stuff. You always give code snippets and explanations. They're not as fully built out as usually like docs are for a Redwood thing. But I think you are an engineer who does appreciate the importance of writing. I remember you and I have even talked about this, where you were saying you want to improve your writing chops.

That's great because you don't need to be a great writer. You just need to be able to sit down and externalize your own thoughts about the code. Because if you're the one who wrote the code, you are the one who should at least give a baseline explanation of what it does. This really frustrates me about the older generation of programmers who have this idea that docs, writers, and engineers are separate people. I just don't really think that works very well.

00:02:49 - Peter Pistorius

Yeah, it's like you don't have to be a good writer, but you should be a good explainer. Using words to do that, or videos, or comments on pieces of code, is a great way to approach it.

With Snaplet, I certainly have written a lot of docs and I'm really getting into it. I don't know if you know that Tom Preston-Werner created this thing called Readme Driven Development. It's a methodology where you write the docs first before you write any code. There's a blog post on it. It's really great.

00:03:14 - Anthony Campolo

On episode four, when we had Tom on, we talked about this and the whole history of Readme Driven Development.

00:03:19 - Peter Pistorius

Oh great. It's an amazing way to think and approach a problem. I always try and bring that with me when I'm writing some code.

I have a funny story. I worked in the United States for a while, and I actually worked for an energy company in Oklahoma. When I went to the interview to see if I was going to get the contract or not, the VP of engineering or whatever, he had a very fancy title. We sat around a desk with all his engineers and he asked me. He sat across the table and he said, Peter, tell me about your methodology. And I was like, you know, I'm a practitioner. I write code. That's what I do. So I was sitting there trying to figure out what he wanted me to say. I was like, methodology, ontology. Is it scrum? I don't think so, because I'm a contractor, a single individual.

I looked him straight in the eye and I said, well, I practice something called dumbass driven development.

[00:04:04] He just paused for a couple of seconds and then burst out laughing. I further explained to him that it was basically a concept where I try to write code in a way that is easily understood by myself. A couple of months down the line, I took that to Redwood JS as well, where I try and oversimplify almost everything that I'm doing to the point where there's very little fancy stuff in the framework.

00:04:24 - Anthony Campolo

People have said this when they try and start contributing to Redwood. They'll start reading through the code and they'll be like, this is really readable. This is really understandable. It's such a large, complicated framework that people usually think it's going to be extremely hard to get spun up with it. But then once they actually go into the code and start reading it, the response is almost always like, oh, it makes sense and it's clear. And I think that's because you have put all this work into making the code comprehensible.

00:04:51 - Peter Pistorius

It's because of dumbass-driven development.

00:04:53 - Anthony Campolo

There you go.

00:04:54 - Christopher Burns

You gotta make it as simple as possible. One of the big things that has happened since we last spoke, you could say that your everyday life has changed from when Redwood was conceived and started. It was your full-time job. All you did was work on Redwood. But then you wanted to start a company. You saw a problem and you started tackling it, meaning your time on Redwood went down.

How do you feel about it? Do you feel like you've handed off that gantlet, that burden, to the community to now sustain? Or do you feel that one day I'm going to go back in and change everything all again?

00:05:33 - Peter Pistorius

I've definitely handed it off. That's not to say that I'm not watching. I glance over things all the time, and I look at PRs, and I'm constantly in the Slack channel. I feel more that I'm part of the community now than a contributor. It'll always have a special place in my heart, but definitely not on a code level anymore.

Maybe if there's some interesting problems that arise, I wouldn't be able to stop myself from contributing. But not right now.

00:05:58 - Anthony Campolo

I think you'll get involved with React Native stuff. You're a React Native developer. So once you start doing that, I'd be curious.

00:06:03 - Peter Pistorius

Yeah, my journey is somewhat interesting. I started out in [unclear], then I went to iOS, and then I went to React Native. I've always enjoyed mobile development, but I think that the web is just for me. It's an open platform and I enjoy it more than the closed ones. iOS and Android? Yeah, I don't know. Probably not. I'm all for the web.

00:06:22 - Christopher Burns

It's such an interesting paradigm to shift between React and React Native. That changes the whole bundling and everything around that. I'm sure we could get into a full episode about React Native and how that will come to the Redwood framework sooner or later, but we're here to talk about what you've been working on and what you've been building. It's poked its head up a few times, and now you're really starting to get it growing, starting to want feedback. Obviously, instead of me explaining what it is, I think it's best if you explain what it is.

00:06:56 - Peter Pistorius

When we're coding, and when you're coding a SaaS product or a product that speaks to a database, there are these two things that you focus on. The one is the code and the other is the data. And during development, we have really great tools for dealing with code. We've got Git, we've got GitOps, we've got great text editors and amazing debugging tools. Your code runs against data.

Developers typically look at data in two ways. I read from it and I write from it, and there's some kind of structure that's an abstraction, like an ORM, that I use to communicate to these things, to the database. The one part where we don't have very good tools is for the database, and specifically the data inside of it.

Snap is a tool for developers that will copy your production database, transform the information, the private information, and then restore that to your development database, either on your local machine or in the cloud so that you can code against actual data. But it's important that it's actually giving you developer primitive tools and workflows that are very similar to how you would approach your job when it comes to code.

[00:07:58] So there's a CLI, there's a portability pipeline in order to copy, transform, and then restore. And we're just getting started. We're going to keep adding more development primitives like callback functions in order to handle the transformations of the data.

00:08:11 - Anthony Campolo

So why does the data need to be transformed? Why can't I just take my whole production database and dump it on my laptop and take it with me to Starbucks?

00:08:18 - Peter Pistorius

Well, you could do that, and a lot of us do. It's something that I have done throughout my career several times. But that means that you have people's private information on your laptop.

Usually the reason why we do that is because we don't have a good process to strip out the private information, or we don't have a good process to generate seed files. Writing seed files and maintaining them is a terrible experience. So what people do is they just copy production and you have people's private information.

So the idea behind transforming it is we'll surface what fields in your database are private, and we'll make suggestions for how you can transform those into fake values, so that you can code against something that looks like production but has none of the private information in it. Doing that allows you to have the performance problems that you might actually receive in production.

You can also self-service your snapshots. You could run a CLI command, copy your database in real time and restore it in a couple of minutes, and then fix a bug in production, not fix a bug in production, but have the data so that you could figure out what the bug is in production.

00:09:14 - Christopher Burns

One of the big highlights that you've talked about here is that when you're starting a project, the real value and use case for snap is not fully apparent. But then as soon as you start dealing with real data, personally identifiable information, PII, GDPR, loads of countries have security measures to keep people's data safe, and sometimes it's not kept safe. If you're a European, we obviously have something called GDPR. If things get leaked, like personally identifiable information, then the companies can be fined for that. So there is a reason for companies to want a secure method of keeping personally identifiable data secure.

But that's just one aspect. I think the other aspect that we tend to look down upon is that when you're working in a startup or a SaaS product, your company can be moving really, really fast. Data model changes daily, weekly, new fields added, fields taken away, data migrations, two different types of data migrations, Redwood and Prisma and all of these things.

[00:10:27] When it comes together, you built a seed file in your first week to go, okay, here's some data that I can start playing with. And then by the 10th week, that seed file is completely out of date because you've removed 20 fields and added 50 more and 20 more relations. So that data is now unrecognizable by the seed file.

And you say, okay, just update the seed file. Yeah, but every time you do a data migration, you don't want to update your seed file.

I've actually used Snaplet a few times, and when I say a few times, I've pretty much used it all the way through the betas and I use it today. So that's my disclaimer. The way it allows you to handle data, it completely removes risk in your mind. For example, and this is my favorite use case, I'm just going to say it off the bat, when it comes to migrations, how do you test your migration? You're adding new fields or removing old fields. Oh, just pull the live database, run the migration, see if it works.

[00:11:26] But what happens if the data changes in unexpected ways or an error happens? You don't want to be running that migration for the first time on the production database. Snaplet is a really good tool to quickly iterate your migrations to find out what's broken and how to fix it, how to change it. Run your Prisma migration, run your Redwood migration, and that's really where I've seen Snaplet so far outshine what I was doing before.

Because before I actually did have a really complex seed file that, funnily enough, I took from my database. So I took my database, dumped it into JSON, made a seed file, and then went from there. But within, as I said, a few weeks of iteration on the product, the seed file was no longer good enough. And then you're spending resources updating the seed file.

So that's roughly my perspective on this. Having such technology available has now made things like migrations, things like error checking, bug fixing, even just viewing data. For example, you've got to do pagination and you don't want to do pagination on two rows, one row per page.

[00:12:40] You actually have real data that you can test your pagination with and your relationships. And I think it's a really, really interesting space that you are building a platform for.

When I spoke to a startup, they're a SaaS business that's been going like five years, decently sized in the UK, and they say, oh, we have like six people working on just our database. And like three of them are handling the migrations between the schema changes of developers, the backups. And we're getting all of these tools that are coming out right now that are just like, why are you paying people when a computer can do this? We've just got to give the right tools and abstractions to allow it to be easy.

00:13:22 - Peter Pistorius

You know, one of the things that we took to, actually that Tom and Rob Cameron from Redwood JS brought to Redwood JS, was this idea of learned helplessness. Developers tend to do things that they've always done. There's some really painful thing, they just continually do it and they're not really questioning why. It's just the way it's done.

I think our industry, one of the problems is that we don't notice the pain. When we were building Redwood, we tried to actively search for the pain. We said, what sucks about this and how can we improve the process? That's the kind of thinking that I brought to Snap. I want access to actual data. Why am I not able to get it? It's for a couple of reasons, but the main reason is that there's private information in there, and the company that I work for, or the team that I work on, doesn't want to give me access to that information. So how do I make that available? I think developers should be coding against actual data.

[00:14:12] Their code runs against the data in production. There's no good reason why you shouldn't be running your code against that in development. When we code on our laptops, we try to make our development environment match production as closely as possible. So we have log files. If it's Nix, we try to use a Nix operating system, Mac OS or whatever. But the data we kind of ignore when it comes to seed files. We're in this learned helplessness mode. This is how you do it. So let's just continually do this or take this approach to seeding our database. This is a different one.

00:14:42 - Anthony Campolo

Could we describe what the process of actually using Snaplet is like? Because I think when we talk about a subject like this, when it comes to data and databases in general, it's always fairly abstract for people. And I didn't really get a sense of what Snaplet was until I actually used it a couple times. Then once I used it, I was like, okay, this is actually kind of simple in terms of what it does. So could you just walk through, like, if I came to Snaplet right now, create an account, I started with your Getting Started tutorial, dashboard, whatever. What is that process like? Could you walk us through that?

00:15:12 - Peter Pistorius

Sure. Basically, you create an account on Snaplet. When you get there, we ask you to give us your database credentials. You will also be able to self-host Snaplet so you don't have to give us your database credentials, but right now you do. You come to our website, you give us your database credentials.

We then have a look at your table structure and we determine which columns contain PII. Then we give you two operations that you can currently run against the data in your database. The first is that you can exclude data. Often developers will have tables in their database that aren't really relevant for development, like logs, or they partition their tables after they get too big. You can just skip those and you can keep the schema, but you can strip out the data.

The second one is that you can transform data on a per-column basis. As an example, I have a table called users. Inside users, I have a column called email. I can then define a replacement for those values using a DSL that we have.

[00:16:06] So you can say replace these with fake emails. Once you're done with your transformation configuration, you create a snapshot and we have a worker that goes off, connects to your database and transforms the values in memory, and then pushes it up to a bucket where it's saved securely.

You then install a CLI on your local computer. You authorize the CLI to access your Snaplet account and you type snapshot restore. It copies the latest snapshot and restores it into your local database. You can also historically go backwards in time and say, for instance, you ran a migration, but you actually wanted a version from like two days ago. You can just say snapshot restore, version 58 or 102 or whatever, and it will bring back that older version.

And that's the basic process. It's connecting to your production database, copying your data, transforming it while it's copying it, storing it somewhere so that you can restore it later.

Some of the tools that we're bringing out are the ability to use JavaScript callbacks instead of this DSL that we've defined in order to handle the transformations, and we've got a real-time proxy that's coming out too, so you can connect to production in real time and use a read-only connection to actually view the data.

[00:17:10] But with the private information removed and generation, sorry, we're going to introduce two extra operations that you can perform on the data. We actually want to replace seed files. We want to give you really great tools so you can generate data while you're developing. So say, for instance, you add a new column. Generally you would create a seed file so that you can get data in there. But snap can help you there as well.

We'll look at your database and say, oh, hey, this one's empty. You called it user first name. Can we insert a bunch of first names in there for you? How many? 100. Okay. Or let's just fill up the row with the values that are blank.

The fourth operation that we're going to add is something called subsetting, where we can grab 5% of your database but maintain the referential integrity so that you can get a snapshot really quickly. So say, for instance, give me 5% of my users, but the ones that joined most recently, or the ones that are in America, based on some kind of condition. Through giving you the ability to have these tools to approach your data requirements, developers are able to self-service their needs in their development process.

[00:18:09] And that's really important to me. You were saying that there are these companies where there are people that do this kind of job for them, but in a remotely distributed world, I've got to go to these people and say, hey, I need some data, can you make it for me? And they're like, yeah, sure. We'll add you to our project board and we'll get back to you in two weeks or whatever when the sprint's done, and then we'll give you your data. But I have a real need right now, so I want to be able to go in and transform the data in the way that I want it right now. I want to be able to do that.

You saw that in the DevOps world as well, where it used to be the situation where you'd go to some server admin and you'd say, hey, I need a server, or I need a place to store files, or I need to send emails, and you'd have to wait. Then DevOps came around and now you still need to wait.

[00:18:50] But it's getting better. We're getting to the point where, as developers, we can service our needs, and developers outnumber DevOps people. I think it's like 100 to 1 or something. It's even greater when it comes to DB people, and we actually just ignore the database. Developers don't really know what's going on there. It's just this black box where we store things, and you're lucky if you have someone who does know what's going on there.

So I want to bring that world to the developer and say, hey, this is a database. This is how you service your needs when it's related to databases. And that's the conversation that I'm trying to start with people. You can use these things safely. Let me give you the tools to do so.

00:19:21 - Christopher Burns

It's interesting that you said DevOps came around and now we're giving the tools to developers. Do you think we'll see a shrink in DevOps regarding the tools that we give to DevOps, straight to developers?

00:19:35 - Peter Pistorius

I'm in no way an expert, so take what I'm saying here with a grain of salt. We have site reliability engineers who are responsible for the maintenance and upkeep of a production website. And then we have DevOps people, and those two lines are kind of blurred. They kind of fulfill the same roles.

But in my mind, a DevOps person is actually there to service the needs of the developers more so than the production stack. When you have a clear split between people writing features and people maintaining servers, you have to wait. There's this thing of throwing things over the wall. It's like, here's my code, deploy it, or I need a service. Can I have it? And they're like, yeah, sure, there you go. And then you're like, ah, this isn't what I needed. I actually needed something else. There's this boundary between the two worlds.

I think those two worlds need to come closer together to increase the productivity of developers because developers can ship quicker, are more productive, and happier.

00:20:23 - Christopher Burns

I've had a few conversations with people at Prisma and obviously with you, and my perspective on databases is not a worrying one. It's more like, well, I get they store my data, but everything else about databases I just want you to handle. How do I know when my database is now too slow, or my query calls are too big, or it's time to put more RAM into it?

All of these things about database management, I think these new-age tools are going to be able to just tell you with time. Obviously, as your tool is one of them. Why can't I just use live data with the bits removed? Well, now you can with snap. Why can't I just get all my data from the database really easily? Now you can with Prisma.

It's these tools that we're building that I think are really going to not necessarily demystify the monster that is a database to front-end developers, but build a cage where you feel comfortable with the database, because we're building all these tools around it to keep it caged instead of not understanding it to a certain extent and feeling like you need to understand SQL to do anything.

00:21:38 - Peter Pistorius

And you already kind of see that happening, right? That's how we're treating databases as people who are starting smaller companies. We're just like, hey, I'll just get something from Amazon, or I'll use Supabase or PlanetScale or CockroachDB. We're starting to treat them as serverless databases where we don't care about how much storage there is or we don't upgrade them. It kind of happens automatically, where we aren't aware of slow queries.

But if you look at PlanetScale, they're starting to bring that stuff to the conversation, like, hey, developers, your slow queries, or here's reports or ways to figure out where your slow queries are. So I think your intuition is correct there. I agree. We're being given the tools so that we can think about our databases as a platform, rather than just this black box that we don't necessarily understand, and we just read and write from.

00:22:23 - Christopher Burns

With databases being this black box of what we read and write from, what are your thoughts on languages and databases? The language that I've used Snaplet in is Postgres. Does it support any other variants of SQL? Does it support NoSQL databases? Is that something you have planned?

00:22:42 - Peter Pistorius

What we'd like to do is support the popular relational databases, so MySQL, Postgres. The reason why we started with Postgres is because it is sort of the developer's database. It has amazing extensibility. A lot of the products that I admire, like Supabase and Hasura, are built on top of Postgres, and I think there's a good reason for that. It's a super solid database. Not that MySQL isn't.

00:23:06 - Anthony Campolo

What do you think about PlanetScale? Because PlanetScale is the first one I've seen that's actually getting a ton of hype that isn't Postgres because it's MySQL.

00:23:13 - Peter Pistorius

PlanetScale is amazing, and I aspire to give their level of developer experience to people using Snaplet.

00:23:20 - Christopher Burns

PlanetScale is obviously this big one of, well, we're going to use MySQL. And then the first question that I always think of is can you use Postgres with PlanetScale? It's like, no, it's MySQL. And then it's that thing that as a Redwood developer, as one of these higher-abstraction developers, making the choice of a language at this stage I still think is super confusing. We've got so many tools that are making databases easier, but the underlying decision of MySQL or Postgres, I don't even know the difference. Does it matter?

00:23:52 - Peter Pistorius

Yeah, it doesn't matter.

00:23:54 - Anthony Campolo

It's on Prisma to figure it out, because Prisma is the one who's really handling the translation from the Prisma schema to actual SQL. And so the SQL is where you get tripped up. And this is actually, you can do this. This is a really fun experiment, right? A model like a regular old Redwood model, you'd write regularly, do a Prisma migrate with Postgres and then look at the SQL it generates, then do the exact same thing with MySQL and look at the SQL it generates. Is it the same SQL?

00:24:18 - Christopher Burns

Off the top of my head, if you said to me today, will your app work in MySQL, I honestly don't have a clue. That sounds preposterous, but to me, databases are like the least of my worries because I've got so many other things to worry about. Most people say Postgres is good enough because, Azure, Supabase, you can go, okay, Postgres is fine. And then you hear, like, oh my God, there's so much hype for PlanetScale, and you're like, can I use PlanetScale? It's like, no, because you picked Postgres. And you're like, why did I even pick Postgres? What is Postgres giving me over MySQL?

00:24:49 - Peter Pistorius

The storage engine. At the end of the day, for the end user, it doesn't really have an impact, right? You're not thinking about it in those terms, but when it comes to maintainability, simplicity of replication, and being globally distributed, there are concerns there.

But the serverless model is going to take all of those away. Maybe it being MySQL or Postgres is just an implementation detail. Does anyone know what flavor of Nginx their web server runs on? Probably you do. It's probably Ubuntu. But when you thought about picking the instance or whatever, did you think about which version of Linux it was? You were just like, yeah, I'll just pick the most common one.

00:25:26 - Anthony Campolo

I picked the good one.

00:25:28 - Christopher Burns

Obviously I picked the best one. Arch Linux and I installed everything by myself. No, obviously most people go, I need an Ubuntu image with Postgres and Docker already installed. Just go from there.

One of the things I wanted to go back on was we talked about the transformation of data. You've actually been doing some really interesting things in this area. The way that I know is you have basically different categories of data. You have like, I need to replace a name, so you say name dot first name, name dot last name, and then it will just randomly generate names.

But what you've actually been working on is using JavaScript so you can customize that. And what I think is really interesting about this, and obviously I don't know if this is in production because I've only seen it in one of your demos, is that you've actually got VS Code built into the website to allow you to handle that JavaScript function callback.

00:26:24 - Peter Pistorius

The reason why we eventually went that route is because your database columns have type information about them. You're specifying what kind of column it is, whether it's nullable, etc., etc. We want to bring that kind of visibility to developers to say, hey, you can't return null here because this is a non-nullable column. And we think that JavaScript and the combination of TypeScript is a good way to surface that information to people who are programmers, who are not thinking about SQL or database structure when they're doing transformations.

Another one of the reasons why we're doing that is because a lot of people are storing JSON or JSON information in tables. If you ever wanted to replace just one value in a certain key using SQL, or the SQL syntax for dealing with JSON, it's quite difficult. But everyone knows how to just say, okay, object key equals new value, replace the private information. So it feels like a very natural way to approach data transformations from a usability standpoint and from a discoverability standpoint with TypeScript. That's why we inserted Monaco's editor in there.

[00:27:25] But what we actually would like you to do is bring those transformations to your local machine so you can type them out while you're coding, store them in your repository so they become an artifact of the work that you're doing, and use those transformations in your repository to convert your data.

So it's going to start feeling more like a GitOps workflow than a SaaS product where you log into this website, click around, and type code in a little box.

00:27:50 - Christopher Burns

The real big benefits are like, I can just log into a website and do what I need to do, but then I get a basic workflow with a CLI. Me personally, I can find that really obtuse. Really like, where do I even start? Of course I know how to use terminal every day, and this is one of the things that I provided some feedback to you. It's like, if I don't know where to start, why am I even going to type into the terminal? I know I need to type snap something, and obviously the hardcore senior developers that use Linux all day are like, you just type in snap help. Come on, everyone knows you type in the help command.

It's that thing of sometimes I find there's a really good balance of having a website that tells you what to do in the right steps to put into the CLI, and having the CLI tell you what to do, is a really good balance between both. And I think you've actually tackled that really well, the balance between this is the bits I need to do in my CLI, as in the restorations, but then customizing the data.

[00:28:51] That's also pretty good to do through the website, but then different users may want it differently. Some people, as you said, may want it to actually be in the code. It's that balance.

And the hardest thing about that balance is teaching people how to do it. Because if you've just got the code, how are you going to go, okay, that code is doing all this stuff in the background? You're like, what do you mean? When a website walks you through it in a dashboard, it's not complicated, it's just hiding it in a nice UI. It's telling you what to do. It's teaching you. It's holding your hand, which I find CLIs hardly do anymore, if that makes sense.

00:29:28 - Peter Pistorius

I hear you. There's this project called Fig where they have sort of auto-completion. It's bringing that to the table. But definitely there's discoverability using a website and being guided along your path, which is hard to do in a CLI, and it will be both.

But I think when you start working in a team environment where you're deploying rapidly, then you want to have a versioned artifact of what you're doing that other people can review in the PR so they can say, okay, yeah, I agree with the transformations you've made here, or we've just introduced a new column to the database. Let's make sure that it's transformed for our newer snapshots. Did you write the transformation, kind of thing?

00:30:03 - Christopher Burns

That brings me on to my favorite thing that I want to talk about, actions. The only reason I'm saying actions is because I know GitLab and Bitbucket have actions, but everyone was saying just GitHub Actions. What do you think the future of GitHub Actions looks like for your PR workflow when it comes to databases?

00:30:24 - Peter Pistorius

The model that we have now is create some code, have some tests that are validated against the code that we've written, and in order to deploy, let's make sure that all the checks are green.

What I'd like to add to that conversation is that you are considering the data that you have in production, that you would also like to transform it, but then also from a privacy aspect, to say, are we transforming all the PII information in our snapshots? And if we aren't, can we get a red checkmark that says, you're not safely transforming your personal information out of your snapshots, so you're not going to get snapshots from this point onward unless you transform them?

I think from a team and a company aspect, that gives you a safety net to say, okay, we trust the tool. It's telling us where our private information is and it's making us transform it before we get access to that data.

00:31:10 - Christopher Burns

And do you think we'll get to a point of almost a JIT-based database? As in, I've been told I need to go work on a feature, so I open up a PR and then instantly a tool like snap, or a database provider, could give you a URL and say, here's your copy of the database. Then you go away, you do all your tweaks, your migrations, then you come along, my PR reviewer, and say, okay, I need to look at this code.

And one of the big blockers right now is, okay, well, my database is on my local computer now. You need access to my database to see the migrations I run, the features that I made. So it's that balance. Do you think we'll get to a point where the PR flow in these kind of SaaS products will require a unique database that can be pulled down by anybody?

00:32:02 - Peter Pistorius

You actually already see that in PlanetScale. They have this ability to branch databases and create a unique branch of a production database so that you can preview it in a pull request.

I think it is interesting to say, hey, I'm the developer, I have this database on my local machine. But actually what I'd like to have is the database in the cloud. And you see it in some more complicated teams. They're actually not coding locally anymore. They're coding over the internet. They're coding against infrastructure in AWS or something like that, because their setups are so complicated that they cannot actually reproduce them locally.

I think we will start moving towards that when our tools become slightly more sophisticated and this DevOps, GitOps world becomes more aligned. Say, for instance, I wanted the ability to store some files. I usually have to go ask someone who has access to our infrastructure to give me a place to store some files, but there's no reason why I shouldn't be able to self-service those needs for myself in a declarative format to say, hey, I actually want storage.

[00:32:58] If I type that in a configuration somewhere, I get storage. And the same could be true for databases. We're already doing that with migrations, but in a development workflow we can't just provision our own database per pull request. Did that make sense?

00:33:11 - Christopher Burns

Yes, it did. It's a really interesting position where you currently just got funding, so you're currently looking to hire more staff. And this is a perfect pitch to say, please come and work at snap. So what features, as you said, what is going to be added to snap? What is currently being added? What is something someone could work on if they come join snap today? Also, what are the jobs you're looking for in Snap as a way to expand the company?

00:33:41 - Peter Pistorius

We're looking for developers who know Node.js, JavaScript developers, TypeScript developers. We don't really require that anyone has very deep database knowledge because our target audience are developers, and we love that fresh mind that they bring to their lack of understanding of databases because they're solving their own problems. But if you have database experience, that's also amazing.

Some of the things that we are working on are Postgres wire protocols, proxies, in-memory databases, the ability to have callback functions that need to be memory efficient, that run on millions of rows concurrently. There's some really, really cool problems that we're solving when it comes to databases and the code that transforms them.

So I think anyone who's really interested in optimizing the developer experience around data, I'd love to have a conversation with them and show them what we're building.

00:34:30 - Christopher Burns

Where can they reach out to you to have that lovely conversation?

00:34:35 - Peter Pistorius

If you go to our website on our About Us page, you'll see a link to contact us. You'll reach me. It's just me.

00:34:41 - Christopher Burns

There you go. Let's talk about something that I know you've spent a lot of time on, coding in the cloud. This is something that in the last year we've seen start to take off. Gitpod has been a massive player for a while, but also GitHub Codespaces has come along.

00:34:54 - Anthony Campolo

I was going to ask if Peter has tried either StackBlitz or Gitpod paid yet.

00:34:58 - Peter Pistorius

I have. They're amazing. It's really cool that we have the ability just to kick off a machine in the cloud and instantly start working. I think teams that adopt that environment are going to be so productive versus teams that don't.

It's just like the machine is the perfect machine that you need to get your job done, and it's maintained by everyone on the team. So why wouldn't you use that instead of you're the one at your desk that, for whatever reason, Postgres is just not working and you have to figure out the brew command to restart it. And then you're like, why is this log file here that I have to delete? That happens to me a lot. I'm like, why isn't Postgres working? Because I rebooted my machine in some irregular state.

00:35:34 - Anthony Campolo

And this is from someone building a database company, someone who's like, why isn't Postgres working? That's an indictment to the usability of databases if there ever was one.

00:35:44 - Peter Pistorius

Yeah, there's some lock file that wasn't removed between the previous restarts. Then I have to figure out where it is and where the logs are to understand where the error is. It's just so unintuitive.

Actually, this is a good segue into the origin story of snap. I was working at a company called Shutterbug, and this is where I met Tom Preston-Werner. We started building Redwood JS inside of Shutterbug, based on some of the ideas that we had in our own website there. I decided that I actually wanted to work on Redwood JS full time, and I wanted to build my own company eventually, and I resigned.

I gave back my super powerful laptop to the company, and I went back to my MacBook Pro from 2013 because everything else had garbage keyboards. I just wasn't willing to buy a MacBook with a terrible keyboard. So I was coding on this super slow machine, and at first I was like, yeah, this is great. This 2013 MacBook Pro is just as fast as the 2018 MacBook Pro.

[00:36:38] I see no difference. But that was just me lying to myself. And after a while I started noticing the difference. Compile times were becoming rough, so I decided to try out coding in the cloud. I was really enjoying it. You can just put up a super fast machine and the latency was acceptable and it didn't feel like I was coding on a remote computer.

But the one thing that I always hit my head against there was this inability to get access to data. So it's like this machine that essentially, at the end of the day, I pick it up and I throw it in the trash, and the next day I walk to a cupboard and I pull out a new one. I have the tools to provision everything else, like the code and the dependencies around the code. But when it came to the data, it just wasn't there.

That's when I started thinking, how did we solve this before? Okay, I can dump a database, I can restore a database. How do those commands work? And every time I want to do this, I have to sit there and wait for them to finish. I decided to create a workflow for this, and then I realized I could strip out the PII and make it private and make it super intuitive and give native development tools for doing this.

I really think that the further we move away from coding locally, the more we'll need requirements for access to data.

00:37:46 - Christopher Burns

You're currently using GitHub Codespaces as your main tool. Is it still your main coding environment today, because I think you've got one of the new MacBooks, didn't you?

00:37:58 - Peter Pistorius

It is not my main coding environment, and the reason why it isn't is because it's really expensive. I quickly ran out of my free allowance, and I was spending a significant portion of money on coding in the cloud. And the new MacBooks are really great too. I think once those costs come down, it'll be a viable alternative just because of the ease of use.

00:38:18 - Christopher Burns

Because you run a nice little thing called a startup. Gitpod has just brought out a startup program where I believe you can get free space and discounts, but also Gitpod is reasonably priced compared to Codespaces, so I definitely recommend checking it out.

But at the same time, you've bought one of those new MacBooks, so you're probably not seeing major problems anymore like the rest of us when summer came around. Even for myself, my 2019 MacBook just died. It just completely died. You could hardly do anything on it without it thermal throttling. And I started using Gitpod. To this day, I still use Gitpod. I use Snaplet in the cloud with Gitpod. It's amazing the amount of freedom it gives you to just be like, I'm going to load up my iPad and just start typing away on my iPad and everything's fine. It's great.

00:39:11 - Peter Pistorius

Does Gitpod have a concept of long-term storage so you can maintain data in your database between sessions?

00:39:18 - Christopher Burns

No, that's the only one issue. I know you were working on some kind of system with GitHub, as in a cloud database container of your snap data. So that is something that I'm actually interested in.

00:39:33 - Anthony Campolo

When you're doing Gitpod though, would you be able to just take a connection string from a Railway database and just use that while you're coding?

00:39:41 - Christopher Burns

Yeah, you can actually. Gitpod does have Postgres built into it. So what I currently do with Gitpod is, when I boot it up, I basically, using a Dockerfile, log into snap, pull down the snap container. Then I run my Prisma migrations and then there you go. It's ready to go.

If you could necessarily host that container outside of Gitpod, you would get that ability that it wouldn't shut down every time Gitpod shut down. But apart from that, there is no problem with coding in the cloud today because, as I said, the startup process doesn't take that long to get the latest data down in Gitpod.

00:40:20 - Peter Pistorius

What you can actually do with snap today is you can run it in a GitHub Action on a cron job or whatever. You can take snaps, you can run your Prisma migrations, you can restore your data and create a Postgres image that has data inside of it and save it on GitHub Container Registry. And you could just pull that image down. So you could have a database that's pre-populated with data every single day.

This requires some manual steps, and we have documentation on how to do this, but Snaplet will provide this end to end. We've just added scheduling. Part of what we're starting to add is the ability to have a data target. So you have a data source where we copy and transform, and then you'll have a data target. So you can restore to a database in the cloud, or you can just restore into a container or save a snapshot of that in a secure bucket that you can then restore later. We want to make this as seamless for you as possible, and always give you up-to-date data when you need it.

00:41:13 - Anthony Campolo

I had a couple questions about open source stuff that I think would be interesting to get your perspective on, because you're someone who's been involved in open source for so long. I know you've been watching some of these projects. SWC is one that we've mentioned on the show a couple of times, and it's been picked up now by Next. You were testing this out a while ago for Redwood.

I think now that there's this huge, huge community momentum behind it, I know Vercel is going to be having some people getting plugins from Babel over to SWC because they have a huge, huge vested interest now in making this giant ecosystem-wide migration work. Do you think you may be using SWC at some point now that it might be getting closer to prime time?

00:41:52 - Peter Pistorius

I think maybe three or four months ago, I added a PR to Redwood where we tested out SWC as a potential tool for transpiling the Redwood codebase. The problem with SWC at that point was that it wasn't transpiling things accurately enough. It introduced some bugs, but now I'm using SWC in Snaplet as my transpilation tool of choice.

There are still some limitations, one of them being that you cannot have aliases. So if you want to do import from src slash blah blah blah, you can't do that. You always have to use relative paths. The aliases don't work. But it is, in my opinion, close enough to being production ready that you could use it with a degree of confidence.

One of the things that I always loved as someone building a framework was the ability to transpile or create plugins for Babel, and I could do that with JavaScript. I don't know Rust. I would love to learn Rust, but if I'm using SWC, I'd love to have the ability to write transpilation plugins in a language that I understand, and I'm wondering whether that will be extended to the community, because I think there's a lot of power in giving developers the ability to extend the language that they're coding against.

[00:42:59] There are arguments for or against that, but I think there are a lot of arguments for doing that that are more positive.

00:43:05 - Anthony Campolo

What are your thoughts on Astro and some of these new multi-framework partial hydration things that are coming out?

00:43:11 - Peter Pistorius

I haven't really paid a lot of attention to them. I kind of touched on them lightly. I'm not really a fan. And correct me if I'm wrong here, but I think Astro kind of mixes CSS and JavaScript and they break them up in blocks, kind of like Svelte does or Vue does.

00:43:25 - Anthony Campolo

It breaks up even more to the extent where you can use React, Svelte, Vue. They have what are called renderers. So they have plugins for each of these frameworks that allow you to write either an Astro file or a JSX file, or a Vue file or a Svelte file, and then it knows how to handle that and turn it all into a single site that is coherent, and then also gives you partial hydration in this whole islands architecture.

It's a huge sea change in how we think about what a tool like this should do. And there's all these other projects now. I just wrote a blog post where I looked at like five projects now that are kind of doing this. There's also Slinkity, Marko, [unclear], and Qwik. We have episodes about some of these. We have other ones kind of in the pipeline, and I'm very, very, very hyped about all these projects. I think they're super, super interesting. So definitely something that you should keep an eye on.

[00:44:14] You should just give Astro a try when you have a free day because it's very, very fun. You're not going to use it for production tomorrow, but it'll be one of those things. You'll do it. You'll be like, huh, this is different.

00:44:26 - Peter Pistorius

Awesome. I'm very interested in the framework space, but my attention is drawn more towards React-based frameworks. And I know you said that Astro supports all of them, so I should definitely check it out. I kind of just glanced over it and moved on.

Like you're saying, there's so many of them coming out, right? Where do I put my attention? And Remix just got launched, right? That's a very interesting framework, I think, just given that it uses these native HTTP principles, the foundations that the web has been built upon, and it introduces it on a framework level. It's really encouraging.

00:44:55 - Christopher Burns

Remix is actually super interesting because I've not had a go yet with it, but as soon as it came out, I literally had so many people say, is Next and Remix going to merge one day? And I'm like, wait, how do you see that from just this project going open source that they're going to converge? It's like, but I thought they were completely different.

Can you give more to that comment, Christopher? Some people can see Next and Remix in the future as coming closer together.

00:45:25 - Anthony Campolo

I think the reason why people are comparing Next and Remix is because they both take a similar part of the stack and the area and the concerns, which is the front end, the routing layer, and the serverless functions part. Both of them still don't really go too far into the database, although Remix is starting to call itself a full-stack framework and are saying they think of themselves more like Rails than like Next, which I think is really interesting.

So they have no interest in merging with Next. They're trying to build a larger full-stack framework, and they've already built the piece of that that would be the analog of Next if they wanted to have used Next. I think people are probably going to start, some people are going to migrate there, like Next apps to Remix. I already know a couple of people who are doing that. But I still think no one's going to be able to touch Next. They just have too many resources, too much mindshare, and too many people using it.

[00:46:14] And Remix will have its own large, tight-knit fan base, just like Redwood does. But I don't know. That's kind of my thoughts there.

00:46:20 - Peter Pistorius

Yeah, we sort of live on the edge of what's possible, and we try to predict where things are going and we're like, everyone's going to go there. But I think it was just last year that jQuery was still the most dominant library in use. And the same actually goes for MySQL. It's incredibly popular. And WordPress too. We're living in these bubbles of the modern stack, but it's not applicable in general.

00:46:42 - Christopher Burns

You talk about WordPress, there's use for Snaplet with WordPress. You just gotta open that door when you get to MySQL of like, oh, you need your WordPress instance locally. Yeah, snap can do that. But then you start feeling dirty, like, oh, I'm mentioning WordPress and PHP on my website.

00:47:00 - Peter Pistorius

If you have to know, I'm a Zend Certified Engineer. Zend was the company that wrote PHP or maintained PHP back in the day, and they brought out this program where you could become a certified PHP engineer. I still have a certificate. I'm a huge fan of PHP. It really changed my life for the better. Yeah, I wouldn't bash it.

00:47:19 - Christopher Burns

Oh no, WordPress. It's got 40% of the market share for a reason. It's still really good at what it does. Everyone built a WordPress plugin for a reason. Loads of people use WordPress.

00:47:30 - Peter Pistorius

Did you build that in PHP?

00:47:31 - Christopher Burns

Yeah, I did.

00:47:32 - Peter Pistorius

Wow.

00:47:33 - Christopher Burns

Yeah, it's in PHP. I had so many problems, all because of PHP, and I don't even want to go there. It gave me nightmares for a week.

But thank you so much for coming on the podcast for a second time. The first time it was interesting, as you said, it was rural in South Africa with trucks driving past you. There was, what do you call it, a nighttime ban where you gotta be home by a certain time?

00:47:59 - Peter Pistorius

That's true. Yeah, we had a curfew.

00:48:02 - Christopher Burns

A curfew, that is it.

00:48:03 - Anthony Campolo

I am going to release that one because there's a lot of great stuff we talked about on Redwood that we didn't talk about at all in this episode. So for listeners who can kind of bear with some bad audio quality, you will get a chance to hear that conversation.

Peter, thank you so much for being here and for doing everything you've done for Redwood and for the community. When I very first got involved with Redwood and I was just writing blog posts and tweeting them out, you actually responded to my very first tweet about Redwood and my first blog post and you're like, oh, this is super cool. Like, you actually read it. And that meant so much to me and was something that really set a good tone for the community and what it was going to be like working in the community and getting involved in it.

So, so happy that you're a part of it and that you're so welcoming to me and getting into it. And yeah, look forward to seeing where things go with snap and just your career in general.

00:48:50 - Peter Pistorius

Thanks. I think writing software is one of the most rewarding things you can do if you're building it for people. I mean, who else would you build it for? But if you have an audience in mind and you embrace their participation in that, it's just a wonderful experience. And I've often described Anthony as the bard of Redwood.

00:49:09 - Anthony Campolo

It's on my Twitter profile. Actually, it's the Redwood, Redwood bard. Yeah.

00:49:13 - Peter Pistorius

Awesome.

00:49:14 - Christopher Burns

Thank you. And we'll speak to you soon, hopefully. Maybe we'll catch up after Redwood hits its 1.0, a retrospective on the journey.

00:49:24 - Peter Pistorius

Yeah, that'd be super interesting. Yeah. Where the framework is going. That's a good discussion. I think about that a lot, except I haven't touched on Astro and all those other things.

00:49:34 - Christopher Burns

Well, maybe you should become a [unclear] influencer like me and Anthony on where the industry is going.

00:49:41 - Peter Pistorius

Yeah, I'd be open to that. You touched on something where you were like, Remix and Next could merge, right? Or some people are saying that, and I kind of see that. If I have to put my mind out there, I can kind of see where there's this possibility. The possibility is that right now, JavaScript runs in a runtime. It's 99% of the time NodeJS. But we've had a lot of new players entering the conversation: Deno, Cloudflare Workers, all the other ones.

There are compatibility problems of getting off NodeJS and getting onto the other ones, which are more lightweight, use less memory, better runtimes for working on the edge. I think frameworks are moving towards that position because it makes a lot more sense from a usability perspective, a security perspective, etc., etc. And maybe that's where we're all going to converge. Like instead of targeting NodeJS, we're going to target a Cloudflare Workers runtime or a standard runtime that's just a V8 isolate with some HTTP primitives or something. I don't know.

00:50:43 - Anthony Campolo

Yeah, I think that's a very good insight.

00:50:45 - Christopher Burns

There's still time to make a new standard.

00:51:19 - Peter Pistorius

I mean, there is one, like right? Like that's what Remix is using. They're using the fetch standard, right? I actually don't know what it's called.

00:51:25 - Anthony Campolo

I'm going to stop the recording now.

00:51:28 - Christopher Burns

Yeah.

00:51:29 - Anthony Campolo

Oh.