Ep. #133, React Server Components with Tom Preston-Werner of RedwoodJS

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got Tom Preston-Werner. Hey, Tom. How are you doing?

Tom Preston-Werner: Great. How are you doing?

Brian: I'm doing fantastic. I was telling you about my jellybean experience upstairs. Just crushed a bag of sour jellybeans from the Jelly Belly factory.

Tom: I wish I had some jellybeans right now, honestly.

Brian: Yeah. Not too bad. Dippin' Dots is a snack for the future, but I think... Was it Back To The Future where they had jellybeans and he had different flavors? I'm thinking of a different-

Tom: I think you're thinking of Harry Potter.

Brian: Harry Potter, yes.

Tom: Every flavor jellybeans?

Brian: Yes.

Tom: Vomit flavor, you want some vomit flavor jellybeans?

Brian: I'll pass on that. I did go to the Harry Potter World recently, actually. We went up to Universal, or down to Universal, and yeah, I've already taken a chance on the Harry Potter jellybeans. Not for me. But we're not here to talk about Jelly Bellies. We're here to talk about Redwood. But before we jump in, do you want to give a quick intro of who you are and what do you do and how you got here?

Tom: Well, my journey starts with wanting to be a physicist, realizing that's too much math, and then pivoting to computers because I'd always done that as a kid as well as electronics and things. Technology in general. But then got into some startups, that brought me to San Francisco, founded GitHub, did that for a number of years. That was awesome.

Now doing some different things, and one of those things is RedwoodJS, a web application framework I've been hacking on for the last three years, I guess now, with a group of people. Just trying to bring something new into the React and JavaScript, TypeScript space around web applications. Kind of missing Ruby on Rails in some ways, but wanting to write JavaScript these days, and so combining those things as well as investing in some other companies that now are using Redwood.

We keep track of companies that are building with Redwood, companies that use Redwood, startups, and how much money they've raised. We've exceeded something around $65 or $70 million raised by companies that use Redwood as their framework. So it's pretty cool to see people using something that you build.

I love that. I mean, that's why I build things. I'm a builder, I'm an inventor. Really in my mind, more than anything, I do lots of things, but more than anything I see myself as an inventor. I love creating things, going from zero to something.

Brian: Yeah. I've benefited from things like GitHub and Gravatar and other things that you've thrown together, so appreciate you're throwing stuff out in the world. You're our third Redwood guest who's been on this podcast. AJCWebDev is a friend of the show, has been on here at this point three times. Then we had Amanda, who's part of the core team, also join us not too many episodes ago.

Sometime last year, I probably should've had that episode ready to go but just check the show notes instead. But yeah, here to talk about Redwood, and honestly, I think when you guys had the Redwood event last year there was the new landing page. Maybe I'm conflating last year to the year prior, but framework for startups is the thing that got in my head, which is Redwood out of the box does a lot of what...

I'm a Ruby on Rails person, that's what I learned first, and to be able to scaffold your project as fast as possible and be successful... We saw an entire influx of companies, 10, 15 years ago, use Ruby on Rails. With Redwood, I'm curious, you had mentioned the number for fundraising. That's an amazing number for folks who have on Redwood, the framework. What are the things that make it easier for folks to pick it up and be successful?

Tom: Well, we envision it as a bit more like Ruby on Rails where if you're building with Rails you expect to have everything out of the box that you need, the basic components, in order to build and test and run your whole life with building web applications. The same is not really true in the world of JavaScript and TypeScript kind of frameworks. A lot of people reach for NextJS, for instance.

And it's an amazing piece of technology, obviously very successful, but it doesn't really help you with the whole lifecycle of building an application. You're on your own as far as data goes. It's like, well, where are you going to get your data from? I don't know, they're totally agnostic, use anything. Fetch from some random API, use Prisma, but you're on your own, right?

If you sit down and you try to get Prisma working with your Next app, you're going to spend a bunch of time figuring that out. Then how do you test that code? How do you integrate that and how do you mock things out? How do you do end to end testing? All of these things you end up building on your own when you reach for something like NextJS. You're piecing things together.

Coming from a world where things are more integrated, I wanted to bring that same kind of flow and experience to JavaScript and TypeScript, and that's part of where RedwoodJS came from. Just that desire like, "Hey, we have all of these great pieces, all of these open source tools components that people are stitching together but everyone is doing it from scratch every single time."

Then there's no consistency across projects, so if you work at one place with a Next app and a collection of technology around it, then you change jobs to go to a different place with a Next app and a different set of technologies around it, getting up to speed on that app takes a lot of time. If you had more reusability or more conventions, more standards across applications the way that if you go from one Rails app to another, you kind of know how the basic things are done.

Of course, people will deviate eventually, especially as they grow and scale. But you know the fundamental things about how a Rails app is going to work, so you end up being able to slide between jobs a bit more easily so I really like that aspect as well. As an entrepreneur, as a company builder, hiring people to work on my app is of paramount importance.

When you're using something that's weird or that is a collection of things that is different from everyone else, it limits the pool of who you're hiring. You want the pool of people to hire from to be large and to be able to have people go between companies. That's, I think, desirable. And so, of course, with new technology that's hard to make that pitch for, but the goal is that you create something that lots of people can use that has consistency.

That's kind of where we come in and say, "Look, you don't have to build all this integration anymore. We've done the integration. We've chosen these things that work together, use them and you'll be able to really fast, building the thing that you care about, your actual valuable thing. Not all of the underlying technology that you just have to put together in order to build and test your application."

Brian: Yeah. So my first experience of Redwood was quite a few years ago, actually shortly after I had Anthony on the podcast. I built as fast as possible on livestream, an admin dashboard. We have a bunch of repositories for Open Sauce that we're tracking for the purpose of encouraging contributions, and we wanted to be able to highlight different projects, to just mark them as featured.

I threw this together pretty quickly. One of the beauties of this is I was using Superbase at the time so to be able to point my Redwood to my PostgreSQL URL that's hosted on Superbase, pretty straightforward. I think Superbase was also my auth provider, so connecting Redwood to my auth provider, pretty straightforward.

Then at the time Prisma wasn't quite magical with Superbase at the time so we actually opted for just manipulating our own SQL queries at the time. But today, now, it's magical. I guess what I'm getting at is to build on top of an existing Redwood project, I can say from first hand experience it's pretty nice. The thing that we've centralized on for hiring frontend folks is if you know NextJS and you know Tailwind, you can pretty much be dangerous, day one.

But we do fall off because we aren't using Redwood for our main project today, it's that when you touch anything backend infrastructure, which infrastructure is an, air quotes... It's not too deep. We just have an API. That's where a lot of folks, they feel like they have a barrier of entry or a learning curve. We have a framework that we used to build the API but it's a framework that specific people know, which is NextJS.

But the beauty of when I learned how to code 10 years ago using Ruby on Rails, it's like a lot of that infrastructure, things like active record and authentication, there was a, "Rails Way." So I guess the question to you is there a Redwood way? Is that the hope?

Tom: Certainly. And I think we go further than Rails does. For instance, we help you to deploy to all kinds of different deployment providers, so if you want to deploy to AWS or Render.com, or Fly.io, or Netlify, Vercel, we have adapters for deploying to all of these different providers that make it really easy to do that. You just Redwood setup AWS, essentially.

Then we'll add the stuff to your project that allows you to now deploy to AWS. Or authentication, right? Rails isn't really particularly opinionated about authentication, you kind of add that on via plugins. It's not built into Rails itself, or at least it was not when I was using it. So we wanted to go further and say, "Hey, you're going to use auth probably. Right? And so let's make that easy."

So we have a bunch of adapters for authentication, AuthZero, Superbase, Clerk, super popular. Whatever it is that you want to use, or build your own with your own database. We have DBAuth which we wrote so that you could host your own authentication in your database, like we used to in the olden days, so you control everything, you own everything, you don't have to pay anyone anything to do that. But you're more responsible for security, obviously, your own security.

But you have the option to do it yourself or use a third party system, and it's just a simple setup command. You run one command, you get all the code dumped into your repository necessary to do that, and you go on your way. So we're trying to go even further than Rails does in having a Redwood way. But being cognizant that not everyone is going to agree on auth solutions.

Where people really don't agree are the places that we try to build these sort of adapters. No one is going to agree on being like, "Oh yes, we'll all just deploy to AWS." That's just not a thing right now. Or, "We're all going to use AuthZero." That's just not an agreement that everyone is going to have, and things like CSS, right?

We make it really easy to use things like Tailwind, but we're not going to force you to do that because not everyone is going to agree on how you should solve for CSS in building your web application with React. The things that we can agree on or at least the things that we've said, "If you don't agree with these things, then probably Redwood isn't for you.

You're going to use React, you're going to use Prisma, you're going to use a relational database." And that's not entirely true, you can use whatever Prisma can use and Prisma can use some non-relational databases. But we sort of envisioned it as being primarily like, "yeah, I'm building a SaaS application of some sort." In which case you're probably using a relational database, but whatever.

You're using Prisma and you can use whatever Prisma allows you to use. You're going to use GraphQL to do your fetching from the backend to the frontend, you're going to use Jest for testing. We made these decisions, they're going to work great if you just figure out how to use them, read the docs, and you're going to love it.

You don't have to make those decisions but that's not going to work for everything. So yes, there's a Redwood way but there's also enough flexibility that it's going to work for the kinds of things that you do need to make specific decisions on, based on your application.

Brian: So in preparation for this call I read through a blog post you had written about the next stage of Redwood and the evolution of the framework. There's a couple of new decisions or new options that are going to be unveiled for Redwood pretty soon. Things like React server components is top of mind for a lot of folks and there's a lot of conversations on whether this changes...

Even the Jamstack, how the outlook of the Jamstack looks like with the admin now we have server side experiences that we can now opt into. So whether the server side or serverless side, so be it, but now we have that. We have edge runtimes like with Deno and Bun and a few others. So what are some of the big changes that are upcoming or actually even have been updated for Redwood?

Tom: Yeah. Well, the biggest change that we're contemplating right now and we've started is to implement React server components. It's become pretty obvious that this is the future of React and we want to be a big player in that arena. Right now we have essentially just NextJS with their implementation, so there's not a lot of options as far as how do you use this, and of course NextJS is heavily controlled by Vercel.

We want to be a bit more untethered than that, unfettered to a specific vendor. We want to be truly agnostic to vendor, like a true open source project that's not really controlled by a for profit company right now. Redwood is that, totally open source, MIT License, not really associated commercially with anything right now, internationally.

I fund it myself because I like the purity of open source and I'd like to make some money with Redwood some day, but it's not the primary concern right now. The primary concern is building something great and building an amazing community around it. React server components and being a truly first class offering in that regard is what we're working on, and this opens up some really interesting things for Redwood.

So like I said before, right now if you're using Redwood, you're using GraphQL to fetch from the frontend to the backend, using a data fetching pattern that we have called Cells, where you do your data fetching. It's really slick. It's probably the best way that you can use GraphQL, the easiest, slickest way to implement it front to back. We make it super easy to implement your GraphQL API and then fetch from it.

But it's still overhead, it's still something that not everybody wants to use. And so with React server components, we get into a model where we're going to allow you to not have to use GraphQL. You'll be able to reach directly into your database, so you'll probably still use Prisma, though you wouldn't have to. You could just fetch from an API, the same way that you do with Next.

It becomes more agnostic in that component. I think we see that in this modern web development world, that people do want to reach more directly for things sometimes into their CMSs or other spaces without having to go through an intermediary thing to get there.

So we're going to adapt our cell pattern, and in cell you're declaratively saying, "Here is some kind of a query," and right now in Redwood you specify your GraphQL query and that executes client-side in the browser to fetch from your GraphQL API backend. But with cells in a React server component world, a cell can run server side and it can reach directly for Prisma.

So you might have your query instead of being just a GraphQL query, specified, exported, you'll have a function that you export that is essentially your data fetching and it says, "All right, give me my database which is my Prisma object, and then let me run a Prisma query on it and get my data back." Instead of that going over the wire, that's now going to execute server-side.

So you have all of the benefits of being able to do that and executive server-side which avoids a back and forth from your client to your server and conceptually becomes simpler to think about. Then there's no GraphQL and of course with GraphQL you're having to define your SDL and there's just more machinery. You get some really great things when you have GraphQL like, hey, you can consume this API from literally anywhere, super easily. But the burden of creating a good, performant and secure GraphQL API is non-zero, let's say.

We want to make that friction go away. At least when you start with Redwood, you can start very easily. This is one of the challenges with current Redwood, is you have to be pretty serious about what you're doing because there's going to be some extra overhead initially. That's going to make your life much easier in the long run, but it's hard for people to get started so we really want to open up the top of the funnel to everyone who is like, "I'm going to hack on something on the weekend. What am I going to reach for?"

Right now people reach for NextJS, primarily. We want them to also be reaching for Redwood, so reduce the friction to get started. We started upmarket, right? We built this really sophisticated product with long term maintainability and large scale application development in mind, and Next started kind of downmarket like, "Hey, here, hack this thing out. Who cares? Whatever. Here's your data fetching, it's a function in your same component."

There's no overhead, zero overhead, so they started downmarket and they're going upmarket. We started upmarket and we're going downmarket. That's one of the reasons that I really love React server components, is because it's a beautiful model for incorporating this easier paradigm of a transparent API. We'll add, of course, the ability to do submit form data and do mutations and stuff. Mutation not in a GraphQL sense, but just changing something on your server and make it really easy.

That's one of the big things, and in order to do that we're changing to Vite, V6, version 6 of Redwood was released recently and that includes a change to using Vite as the bundler by default. Much faster build times, much faster locally to run, just more performant overall using Vite instead of WebHack which is what we were using before.

You can still use WebHack, actually, you can opt to use it still. We'll deprecate WebHack. WebHack is deprecated, so to speak. We'll remove it fully, eventually, once we get most people migrated off of it. That's another thing that we've had to change in order to get to where we're going. It's all the challenge in implementing React server components because they're so early and there's not a lot of super deep documentation and so we're having to talk directly to the React team to figure things out and just hack on Vite so that pull requests to Vite to get certain things working.

But we're hoping that it pushes the whole ecosystem of React server components forward and that we see more options for people there because having that kind of lock in when you want to use React server components is not, I think, a good thing for the ecosystem overall. We want to be there to help define how all this works.

Brian: Yeah. It's still extremely early and I think with the change of guard at the React team over at Meta, we're seeing a very interesting evolution when it comes to the React ecosystem as a whole. I'm personally excited about because I basically did all the learning, I know how to use React, I know how to use the frameworks, know how to use all the tools that you had mentioned.

But now to be able to opt into the next thing, it's just a little bit of somebody needs to blaze a trail and I'm happy that folks like Redwood are doing this for us so that we can have a nice little on ramp into cutting edge technology. I did want to actually talk through some other things you had mentioned a little bit before we hit record around Redwood realtime and Redwood studio as well. Can you explain the Realtime feature?

Tom: Yeah. So we're bringing some realtime features to Redwood, specifically around GraphQL. This is maybe not going to be as relevant in the future when you're using React server components and you're not using GraphQL. But for a bunch of the users that we have today, adding realtime capabilities is really important. This is around realtime GraphQL, subscriptions and what they're calling live queries in GraphQL.

Subscriptions are the official GraphQL solution for pulling down realtime information. This is almost in, it's kind of in, but it's not... I think it's actually in V6 released, but we need to do some patches around it because something ended up breaking it, I think. Anyway, very soon you'll have realtime GraphQL capabilities.

It's going to be as easy as saying, "I want this query to be realtime," and it'll keep the connection open and you'll get your realtime data transferred down. There's two different ways, like I said, subscription is one way and the live queries is another way. They're similar but slightly different, so you'll choose one or the other depending on your specific use case. But that's coming very soon.

Brian: Very cool. Yeah. Subscriptions is something that I played around with a lot. I actually enjoyed GitHub because of my GraphQL work, it's how they noticed me at first. I spent a lot of time with the ecosystem team, working with the GraphQL things to help build more examples of how to leverage marketplace integrations.

A bunch of boring stuff. Subscriptions were the thing... it was a non-starter. GitHub's investment in GraphQL has pretty waned a lot, so that's their story to share. But yeah, I was pushing pretty hard on being able to leverage things like subscriptions, not hard enough because I moved onto other things like actions. But it's something that I just haven't played a lot with. It's exciting.

I think my take on Redwood and probably what I ended up using Redwood for is we'll be hiring someone really soon, a new engineer, and so far successfully we've had a interview project. Something small enough, usually a top couple folks will just be contracted to build the thing.

We did an admin dashboard because we have all the pieces to be able to build that admin dashboard, having it easily scaffolded with Redwood is probably where my head is at for hiring the next person. I'll keep you informed on that experience and how it goes. We've just talked about the next engineer and how we hire and what skillset we need.

I think this will actually give us a good framework to see skills and pick the best person for the job. Yeah, the other thing I wanted to ask about is the Redwood studio before we wind down. You had mentioned that in passing.

Tom: Yeah. Studio is something that we've been developing for a while. It's not generally available yet. But the studio is going to be an application that you can spin up alongside your Redwood application and it's going to leverage the Open Telemetry work that we've been doing in the framework, that will report metrics like telemetry, about your application to yourself for consumption by some kind of data observability platform that can consume Open Telemetry.

But while you're developing, you'll be able to direct it at Redwood Studio and see things like every request that you make, how long it took to execute. You can dig into that and see where the time in that request is taking, and specifically one of the most interesting things, what are the database queries that are being issues. So if you're using Prisma, then you'll be able to see the SQL statements that were executed and exactly how long they took.

You can introspect all the GraphQL statements that are being made, what fields are being request. How that all turned out in reality and what data was being sent across the wire in these various layers. So it's just an incredible introspection tool for using app development time. It's kind of like a New Relic that you're using locally, but then you'll also be able to hook this up during production to get that same kind of data directly out of the framework without any additional work.

It's just a really nice way to work with your application and see what's going on. Instead of trying to dig into the network tab of your browser and you really only see one side of it, you can see how GraphQL is working. One place to see both, every request that comes in as well as everything on the backend. That's one thing that studio does. It also integrates the GraphQL playground in a better way and makes sure that you can use authentication there, which has been challenging before.

So if you have an authenticated GraphQL API, getting a playground to work well with that can be quite challenging. It integrates the authentication that your app is using to make that work really well with the playground. Then we're adding other things, we're working on a mailer right now, an official mailer solution and then the studio will host an SMTP server where you can direct your mailer from your application to send actual, real emails so that you know that they're working. This is not mocked out, it's actually receiving the emails that your app is sending via this mailer code that we're writing.

Brian: And this is all local, not using a SEN grid or anything else behind the hood?

Tom: Yeah. This would be local, yeah. So as you're developing local you want to be really careful not to send real emails while you're in development or staging, so during development you'll be able to send those emails, configure it so it's sending it to the studio application. Then it has an incoming list of emails and you can see them and exactly what generated.

So really trying to solve where you see what's going on with your app and what areas do you need that might be a sink for things like sending notifications, emails and other things. All of that will go into the studio product.

Brian: Very cool. So before I move over to picks, I did want to ask a question for folks who are maybe intrigued about what they've heard about Redwood. Where can they get their questions answered or get started?

Tom: Yeah. Well, best place to start is to go to the website, RedwoodJS.com. Then in the header you can find links to our community. We have both a Discourse forum, that's questions and answers. It's a really great resource. Tons of stuff has been discussed there so you can search for things and maybe find your answer in that forum. Then there's a realtime chat, we use Discord, we have a Discord community as well. Those are the two best areas. We're on Twitter, of course, or X or whatever it's called these days, and you can find us there.

Brian: We call it 10.

Tom: 10? We call it 10 now? Geez, I don't even know. Whatever, you can find us on there and ask us questions. You can find me at @Mojambo on that site and ask me directly. I'm happy to answer you. But yeah, we have a really active community on GitHub of course if you want to submit an issue or a pull request. We have a great, active open source community.

We really try to engage people and be responsive to open source and we have hundreds and hundreds of people that have contributed to Redwood and we really love that. We really love seeing new community members. Everyone that's on the core team came on through active development and really helping out with Redwood. Everyone there is a believer by coming in and helping out.

Brian: Yeah. That's so cool. I'm a big fan of open source and it's nice to see the team grow and evolve based on contributions made. So folks, check out RedwoodJS.com and check out Redwood for your next project. So now I want to transition to Jam picks, these are things that we're jamming on, could be music, could be food related, technology, all of the above.

Everything is on the table. I've got a couple of picks if you don't mind me going first. My first pick is... A lot of my picks have been around AI and testing Open AI stuff and writing blog posts on it. We have figured out for Open Sauce what our AI toolset is, which we have called Repo Query. We started with a Chrome Extension which is Open Sauce/AI. Do a bunch of Copilot X type features, generate PR descriptions and test. I don't want to say it was trivial to implement but it was pretty...

We have two interns who implemented that stuff, so pretty straightforward stuff. Then the broader vision is this thing called Repo Query where you can index a repo. We built a CLI, unrelated, to be able to bake repos and get insights into those projects but the next step, the evolution of that is you can use AI to ask questions based on the repos that you have got insights from.

General questions of how to get started, how to make contributions, what's the test pattern or the test sweep, how do you write a test, et cetera. The ultimate goal, I've got a broader vision which I've been sharing with some trusted folks around being able to identify contributors who are up and coming in a project to reach out to because a lot of times folks...

You might look at a project on Redwood and you might say, "Oh yeah, let me reach out to David." Well, David has got a lot of folks reaching out to him. Who else should I reach out to besides David? And we'll be able to answer those questions is the goal. So just getting started, just got to the point of Azure literally today, and looking forward, by the time this podcast is out it'll probably be embedded into our product.

So this is like the underlying infrastructure for some cool features we have planned. But my other pick is going to be the Jelly Belly Factory, which it's something that I think when I first moved to the Bay Area, my wife had befriended someone in the local neighborhood who told us about this. She's been taking the kids there probably every other summer. It's like, "Let's just take a day to drive up the 45 minutes or the hour up to Fairfield."

It's kind of like the Willy Wonka experience where you walk through, you get to sample jelly beans and see how jelly beans are made, and then obviously you go into the gift shop and you get to pick the jellybeans that you can take home. So I've been feasting on jellybeans for the past couple days, because now that my kids are older and they can read, they're picking out all the weird flavors. My wife got a bottle of Rose jellybeans as well, which we haven't opened that up yet but I'm sure they taste disgusting.

Tom: I didn't know that was a thing, rose jellybeans.

Brian: Yeah. They have a lot of interesting flavors. I thought growing up the weird flavor was buttered popcorn, but we had talked about Harry Potter flavors which they've gone completely off the wayside of what you should put into a jellybean flavor, so they've got all that. But then they've got pretty cool, interesting and new flavors that they're testing out. So if you're in the Bay Area, highly recommend, take the drive up even if you don't have kids. Drive up to the Jelly Belly Factory, make a day of it. It's better than sipping wine, eating jellybeans.

Tom: Well, the next brunch that I host I'm going to be serving rose jellybeans.

Brian: Yes, perfect. Tom, do you have any picks for us?

Tom: Yeah. Well, I might do a little self promotion, so my pick is going to be the upcoming RedwoodJS Conference. Our first in person, real conference that we're hosting for RedwoodJS. It's going to be all about React and the future of React, and the various components that we use at Redwood.

We have workshops from Prisma and Apollo, GraphQL, as well as FixieAI which they're going to do a workshop around how to use LLMs using their AI.jsx software that they've created to make it easy to integrate LLMs into your application using React components that represent the LLM technology. So if you're into AI and LLMs you'll really like that one.

Then two days of talks, and we're going to have amazing talks about design, security, entrepreneurship. It'll be everything in and around developing a web application and of course all related to Redwood, but not exclusively Redwood. Redwood is the reason that we're there, but really it's about building a web application today and what makes that work and how do you do it well, and who do you want to know when you're doing that?

So really I'm excited to bring together an amazing group of people. This is going to be September 26th through 29th in Oregon, United States. It'll also be live streamed so you can go to the website and pick up a live stream ticket as well, and that's go to the website RedwoodJSConf.com, and you will find all the details there.

Brian: Perfect, yeah. Actually I'll be there in person and I'm looking forward to hanging out with folks who are building on Redwood and hearing some stories, and all their interests out into production, live, supporting real customers and live products too, as well. Which is honestly the value of getting in the same room to talk to other folks, to talk shop about how they approach problems.

Pretty much every time I get a chance to talk to other developers, I'm like, "Hey, how did you fix this thing?" Or, "I saw this other thing." So the value of being in person, chatting with folks, definitely do that. But also if you're listening to this after the fact, watch it on the website after the fact, all the cool videos.

Tom: Exactly. Do I get one more?

Brian: Oh yeah. Go for it.

Tom: You want to hear about this one. So not only are we building a framework for RedwoodJS, building something with the framework. So this is a friend and I, Rob Cameron, who I've known since forever and he's helped build RedwoodJS, he's on the RedwoodJS core team. We wanted to go and build an application with RedwoodJS and I've always wanted something that was kind of like a cross between Twitter and a more normal forum.

We used to have a thing at GitHub, the Team app, you know? Back in the day it was kind of a simple, internal app where people could share things. I've been wanting that experience and the best parts of Twitter to me are where people share what they're building, so we've been building something that we call Spoke.

It's at the URL Spoke.run, S-P-O-K-E dot R-U-N. Go to Spoke.run and you today can sign up to get an account and what we do at Spoke.run is we talk about projects. You can create projects, kind of the same way on GitHub that you can create repos. The URL structure is very similar. But it can be a project about anything.

For instance, I just started working on a trebuchet to launch pumpkins because I always host a big Halloween event up in the countryside, Northern California. Then afterwards we have dozens, dozens, endless numbers of pumpkins and what are you going to do with pumpkins? You launch them, so I have to build a trebuchet. This has become a necessity, and so I'm going to talk about building the pumpkin trebuchet on Spoke and you can follow along.

So you can follow me on Spoke and get updates on building this trebuchet, as well as I'm working on an electronics project. I'm rebuilding an old espresso machine, I'm building out a hand tool woodworking workshop, I'll be chronicling that on there as well. So it's kind of like sharing what you're building and building community around those things, and it could be for a web app that you're building, it could be all kinds of stuff.

So we're just starting with this. You could be one of the first on this platform if you're hearing this, and come join us and show us what you're building.

Brian: Excellent. I just signed up, I'm also looking at this trebuchet simulator.

Tom: As a trebuchet simulator it's quite nice, actually. It's well done.

Brian: Yeah. So if you're interested in seeing this thing live in I guess 2D, you can put in your parameters and see the distance of how far your pumpkin will fly.

Tom: Yeah. You can specify your arm and how much weight there is, and how long your sling rope is, and everything. It's amazing. It's a cool tool. I don't know how accurate it is. We'll find out.

Brian: Excellent. Well, this is exciting. I've got some stuff to play with the rest of the day, I'm going to be slinging pumpkins in my Chrome browser.

Tom: There you go.

Brian: But thanks for coming through and chatting about Redwood, getting us caught up. And folks, keep spreading the jam.