Payload is Rails for JS with TypeScript, React and Drizzle (James Mikrut)

Welcome To syntax, today, we have James Micrant on today to talk about payload CMS. It's actually been a while since we've done a podcast cast on different CMSs that are out there.

And I thought that this one would be interesting because I was I've been keeping an eye on Payload for a number of years now and trying it out and whatnot. And they announced some stuff A couple a couple of weeks ago, which is basically you can use Drizzle with payload and it will out the other end. You set it up. It will give you access to the Drizzle ORM so you can use it just like you're doing. And I have this thought. I'm like, Okay. Well, like like, payload is a CMS.

And with that, you get you get a nice admin UI, You get authentication. You get a rest API, GraphQL API. You get an ORM. You have roles and users and holy and Migrations. You get all this, like, cool stuff along with it. And I was I was kinda, like, thinking, like, okay. We just built a syntax website with, like, an ORM. And For all the, like, admin stuff, we had to build our own UI. And I thought, like like, why wouldn't you use Payload or some sort of CMS that gives you the orm access directly.

At the very least, if you want the ability to just Have a admin UI to edit your content. That seems kind of nice. So that's kind of we're going to talk a lot more about what payload is, but that's kind of my whole thought behind This type of thing. So welcome, James. Thanks for coming on. Thanks for having me. Wes, I think you should write all the marketing copy for my website

Because I agree completely with what you just said. I I have a lot of thoughts about this.

I can dive right in, but maybe I should kinda give a primer about my thoughts of where payload is going and, I think what makes us a little bit different than just a regular CMS first Yeah. Yeah. Let's hear it. I've been doing this stuff for a very long time. I don't know. 12 years, 13 years.

And, I was doing it in an agency setting, so I was, like, having to blast out very technically complex digital products Over and over again for very different use cases. You know what I mean? Like, some of them could be, like, product configurators and other ones could be full ecommerce, headless ecommerce, of course.

Some could be internal enterprise tools or enterprise websites, whatever.

But when you're building something, especially for someone nontechnical, Every single time, you need to have an admin panel. Not just for website content, but you have to allow, Like, nontechnical bid business administrators to log in and see customer inquiries and manage customer support tickets and Anything. You just need to have an admin panel.

And I found myself in the early days rolling my own admin UI Using something like Laravel on the back end. Right? So Yeah. You get all the goodness with Laravel, but then you're kinda They have admin panels off the shelf that you can use, but they're they're that you still need to, like, extend them, and you still need to make them nice for people that are not technical to not get scared away. Right? Yeah. Just a lot of work went into those types of things. And I tried to, like, use the different available headless CMSs to their extent, and some of them are pretty good. I think right off the bat, my favorite is Keystone, like, big time. Yeah. I then in Keystone too. I have a I have a course on Keystone. I know you do, and I respect that. I think you chose wisely there.

They're They're they've always been inspiring to me, and I've used Keystone back in the day. So we took some some of the things that we needed, like Keystone was doing right, and we were inspired by. I never really looked at their code. I never got into the back end of Keystone too much.

For example, their access control. Credit to Keystone on that one. That's good stuff. But we needed more. We needed layout builders. We needed, global's, like one off pieces of content. We needed, just a couple features that Keystone couldn't provide, and I'm looking for a silver bullet. You know, like, as an digital agency, I wanna build things fast, Build things well and be able to maintain and extend them in the future. And so that's where payload came from.

And to your point, like, I probably could have built a lot of this stuff using an ORM from scratch, but then I gotta open up my own endpoints. I gotta integrate a third party auth provider. I gotta Wire up access control so different roles and different people can access certain things, but not others. Maybe even on a field level, like Hyde fields, I have to build that entire, like, layer of business logic in to protect certain types of data.

And at the end of the day, you still don't have an admin panel, then you have to go build the whole admin panel.

But that is literally why payload exists.

That's it.

Maybe 1 more thought, and then I can turn it over to you guys quickly.

I wanna stop calling Payload a CMS. That's gonna come out soon, very soon. Oh.

I think it sells us short to describe payload as a CMS because we are so much more than that.

Our biggest customers are building things that have nothing to do with websites or blogs. Yeah. We're building full on internal tools. So we're gonna, like, widen up our our positioning a bit.

You'll still be able to use payload as a headless CMS,

but, yeah, there's gonna be some things coming up soon. Interesting. So what and can you tell us what are you gonna call it? That's it'll still be called paid. Okay. Well, because Sanity has that as well. We did ad reads for Sanity for years, and they're like, well, we're not really like We're not really a headless CMS. You know? Like, we're back end, structured content. Yeah. Where your data goes. Yeah. They called it a content lake, which was kinda interesting,

position as well. Do you have any thoughts around that naming? I do not wanna make up a word. I'll tell you that.

That that I really this is a problem for anytime in this industry when someone comes up with a new paradigm to do something. Like Yeah. It's almost like you have to force feed that idea into everyone's skull before it even takes a fledgling of a hold. Right? Yeah. And I don't wanna do any of that. I don't wanna do it.

There are companies out there that have been successful Working in some type of, like, enigmatic area of web development that don't have a word to describe themselves, like Supabase, For example, they do a lot of stuff. What is SuperBase? I don't even know.

They probably know, and they probably have a word for it. I just don't know. Mhmm. Or Retool, for example. Right? What what would you call retool? I have no idea. It's not an app framework. It's definitely not a CMS. Admin panel builder, workflow manager, I have no idea.

But we're gonna we're gonna work on it. I just don't wanna invent a word. I'll tell you that. Yeah. Yeah. You don't wanna be having to launch conferences and

Everything around that specific area, especially when people start to not enjoy that that specific item, then it becomes a bit of a problem. That was the Jamstack has that that problem right now, I believe, where Right. It was popular, and now people are saying, oh, maybe Jamstack wasn't it, you know, and I don't think I don't see an app ify using Jamstack

all that much anymore. Yeah. They shut down the shut down the Discord channel, didn't they? Really? Oh, I don't I don't know.

I haven't taken a look at that. I have not not seen that. But it's okay. So not a CMS admin panel. I think it's Important that, like, people aren't just using this for content editors. Right? Like you mentioned, people need admin panels, And Wes and I have rolled our own for syntax.

I've rolled my own previously for level up, but technical people need bulk editing. They need Nice interfaces. They need all these things as well.

So is payload really like that bridge For maintaining

your content, is that really what it is? It's I mean, here's an example. We built payload cloud because it sucks to deploy node apps still that have databases.

And that whole that whole, like, application infrastructure layer, that's all built with payload. And my team uses Payload to manage and maintain payload cloud. So if someone calls in and they have an issue with one of their projects that's deployed, We can help them walk through issues, and we log in to payload to do that. And just like you said, bulk editing and, like, being able to, like, Perform technical tasks inside of an admin panel.

Payload can do all of that. So it's not just for, like, writing in rich text fields. You know what I mean? It's It's just an Appen UI. That's it. So let's let's peel it back a little bit more and and talk about the tech as to, like, where this will will fit in. So first of all, payload is open source, right? You have like a a Payload Cloud option there, but all of the tech behind it is open source, right? And it's all JavaScript

and TypeScript. Correct? Yeah. Yeah. Payload Cloud is totally optional. You can deploy Payload wherever you want. It's just kind of a pain. Like, if you wanna go wire up Together all the services, email, CDN, compute, whatever.

But you don't even need to use that. That's just something that we put out there to make it easier to get started with payload, Frankly. Okay. But you can go run payload on Vercel. You can run it on a droplet. You can whatever you want. Anywhere that can run a docker image can run payload. Awesome.

But payload itself is MIT fully.

It's completely open source, and it always will be. And, It took me a while to get there, and I wish I would have made payload open source sooner. It was you know, there's an old parable that says listen to what your users tell you.

And to the surprise of no one on the planet, everyone said this should be open source. And I was like, well, I wanna work I wanna work on this. I wanna, like, be able to sustain my salary so that I don't have to run my agency anymore. Like so it took took me a minute to, like, get rid of our old fashioned licensing. But when we did, I'm so happy we did, and it will be that way until you're gonna have to pry it out of my cold dead hands for for me.

And I'm trying to like if someone's like riding in their car right now, trying to understand how they would use this thing.

The the like the core idea is that you You bootstrap a payload app, and then you create what's called collections. Those are your data types. Right? And all of that definition is not in a GraphQL schema. It's not in a special Prisma schema. It's in TypeScript. Right? And along with your data types, you have information about access control.

Can people create, read, update, delete? If you have hooks, what happens if someone updates one of these things? Should something run, as well as

The the actual components that are used on the back end, if somebody is is trying to update this data. That's that's right. And it's all React? It's all React. It's all TypeScript. It's config based. Everything we do is code first. Mhmm. And it's all very strongly typed. Like my version to making everything free back in the day, I was also, like, Payload started as JavaScript in the very early days, and my cofounders were like, look, man.

We need to move to TypeScript. Script. And I was like, why don't we just launch it 1st? And they're like, no. We need to move to TypeScript.

They won that battle, and I am so happy that they won that battle. Payload being TypeScript, We've been able to refactor at light speed because of that. Our entire infrastructure is all TypeScript and including the React side, everything we generate types, It's, as bulletproof as you can make it. We almost don't need, like, a schema validator anymore because you're gonna get IDE warnings. Right? Like, It's just such a no brainer that we did that. And, yeah. So it's TypeScript front to back. You everything is in code. Starts with the config, and then it automatically Scaffolds everything just from that one single source of truth. So you don't have to maintain a separate ORM schema

Plus the payload config is just all dynamically generated from that one source of truth. Cool. And and how does that then relate to maybe, like, the front end UIs that people are able to build. Like, is there any way to then have access to those types beyond using, like, a GraphQL API, you know, because that would be typed, I guess? We, export types for you from all of your collections, and

they're dynamic. They're not inferred.

We had to Inferred versus generated types, there's a whole I mean, inferred is Mhmm. Preferable. The way that Drizzle works, I'm sure you guys have been blown away just like me with Drizzle, where, like, you write out the schema and, bam, you cannot screw it up. You're getting yelled at before you even think about Screwing it up. Yeah. And that that's just a beautiful thing.

Yeah. By far, inferred types are they blow my mind, and the the It's just really hard to do it well and especially hard to, like, click through and get, like, The documentation that you want as an engineer, like, if you wanna go look at a type, you wanna look at it.

Inferred types kinda leave a little bit to be desired there, So we struck a balance.

We do generate types that can be then used on your front end, and we do that all the time.

But someday, I'd like to get closer to inferred for sure. Yeah. So what what made you pick Drizzle? Had you used Drizzle before This, was it, your, first time using Drizzle and and maybe

other ORMs considered? Yeah. Can you also explain real quick what Drizzle is for anyone who hasn't heard of it? Yeah. Drizzle is an ORM for any relational database. They support a lot of them. I don't think MS SQL is there yet? That's actually how do how do people pronounce MS SQL? That could be a debate.

I don't have an answer.

But they're, they're a relational database ORM, and they try to stick as close to, like, SQL conventions as possible. So when you're writing drizzle, you're actually writing like a TypeScript equivalent of the actual SQL syntax, and I love that. I don't wanna deal with black magic ever. I just wanna I I wanna understand the underlying paradigms and be able to effectively work toward What I would write in SQL directly, and that's what they really did well. I love that about Drizzle. But, you know, when I was evaluating ORMs, we did a whole community push For, we're gonna add Postgres support. And classically, we are MongoDB only, but we added Postgres. And that was a paradigm shift for us Because a lot of the field types that payload supports are incredibly dynamic. We have array fields. We have block fields. We have, crazy, customizable relationships that can happen at any level inside of a document. Mhmm. And, being able to replicate all of that in a traditional table based structure is a big challenge.

So we did a massive amount of diligence. We looked at Prisma. We looked at K'nex. We looked at Kiesly? Keasly?

Does anyone know how to say that? We don't know how to say anything on this podcast. If there's anything I've learned, will you mispronounce it all?

I can type it. I can't say it.

We liked a lot of them, and our big concerns were performance, number 1. Performance was top for us. We are already quite a bit faster than anybody any other CMS out there, in terms of raw, like, processing.

And, I didn't wanna make any, like, concessions on performance. Moving away from MongoDB where you just get 1 document then you have everything. There are no joins. There's nothing. You just get it and you're done.

We didn't wanna make concessions having to make a bunch of different queries. So if you get to an array field, now you gotta make another query to another table. You could join automatically, but even Prisma, I don't think does that for you, like, Auto joins their different queries, and I didn't wanna have that cascading slowdown.

So that was number 1 for us, And Drizzle handles that in spades.

So we we can we automatically join in all, tables that are necessary to complete the data structure that payload requires.

And, so that was huge, but the other thing was Drizzle actually built us a couple features that we needed.

We needed TypeScript migrations.

I don't wanna deal with SQL migrations like raw SQL. I wanna have a TypeScript migration file with an up and a down function.

And those functions within that, you can not only perform the DDL transformations that you need, but you can also manipulate data. So if you need to transform, say you have a first name and a last name and you need to make another field and you need full name and automatically combine those 2 fields in a migration, Doing all that in TypeScript was a requirement for us.

So Drizzle actually exposed their internal methods from DrizzleKit 2 payloads so that we could use them in TypeScript migrations.

That was huge.

Big, big win there. But in addition, With Drizzle, we could programmatically generate schemas at, like, dev time. So We don't have to maintain a separate drizzle schema plus the payload config.

There's no redundancy there. Like, if we were to go with Prisma, We would have to generate the Prisma schema.

And literally, by manipulating text strings and outputting text Yeah. As like And and that's just a racket that I didn't wanna have any part in. So, with Drizzle, we literally dynamically generate the schema, and then you can save it for production.

But that that was huge as well. So I just I didn't wanna make any concessions on DX, and Drizzle, hands down, was the best choice for us.

I'm really happy about it. We we listen to the community. We ran the whole 9 yards and made it happen. So do you have to maintain now Your MongoDB

implementation and your Drizzle implementation between the those 2 ORMs?

It's pretty Pretty elegant actually. The way we do it is on an adapter pattern, so you have to install your, it's a separate package. So payload itself is Just like what we call the local API, and that is all of the payload functions that execute your access control and your hooks and, payload dot find, payload dot find by ID, etcetera, update, blah blah blah.

But then we have a database adapter pattern where you install the database adapter that you wanna use, and that's a separate NPM package. So it comes with all the dependencies that it needs. And when you install payload, you don't have to install both MongoDB drivers and Drizzle.

You just install either or from that separated package.

But our entire test suite runs against Both of those adapters.

So we have a big integration test suite and an end to end test suite.

Those suites both run against both adapters.

So it's just a config property. You import your adapter, you pass it the connection options and anything else that is specific, And you're off to the races. It is it is more to manage for sure. Mhmm.

We're still a seed stage company. So we've, You know, other headless CMSs have, you know, hundreds to thousands of employees, and here we are 12 people Trying to keep up, but we'll be hiring more shortly, and we'll be able to maintain quite effectively with this pattern, I think. Awesome.

I'm curious about the like actually using it. So you set up all your collections.

You have all your relationships Between your data, you have a couple hooks of when something updates, you might you might have a side effect that runs and and goes from there. When I like, let's say I'm building a Next. Js site or a Svelte site and I want to server side query some of that data. Like, What are you recommending I use to to pull in that dish? Should I know there's a REST API, there's a GraphQL API, there's you can access to the raw drizzle, But then you also have, like, the the payload queries as well. Right? Yeah.

Most cases, if you have direct access to the server, that's gonna be your best bet for sure. That's called the local API, and that, allows you to connect directly to your database. So there's no middleman HTTP layer there. Like, when you go through GraphQL, you first have to go through HTTP Yeah. The server, and then the server runs the query to the database.

But, payload is composable and that you can run it next to any front end. It's just a Wrap her around her. It's just actually express middleware at the end of the day. That's all it is.

We are about to move over to Next. Js, Which maybe we can talk about in a second.

But payload just plugs into any express app, and you can run next. You can run remix. You can run Astro, whatever, Right alongside of payload in the same repo, and that will always be possible. Even if we do complete the move to Next. Js, you'll still be able to use the custom server from from Next. Js and put another front end right next to it. In that way, you have access to the local API directly in Your front end, and you can for server side props or server side anything, you just go straight to the database, and it's fast and efficient. So that That's typically how people would run this side by side or also exposed

the API and just hitting it as In API, are those the the 2 kind of standard ways? And if so, as an API, are are they just hosting it on a a separate domain, like in, you know, API dot whatever Sub w Yeah. We see about half and half actually. So the larger use cases

might generally separate the 2 concerns And run the CMS on a separate full deployment, and then go through the rest of the GraphQL. Especially if it's statically rendered, it's not a huge deal to go fetch that data from a from an API and then statically render. But I'm a big proponent of simplicity, and I think this whole move to headless has Caused us a lot of pain in that process.

Yeah. It's not it's not really rocket science. We're not building rockets. We're building websites for most of the time. And, Yeah. Separating this, maintaining 2 different deployments, making sure that you deploy changes in parallel with each other, hoping nothing breaks while 1 deploys first and the other one's still up. Like, There's just a lot of heartache involved in that. And I think my goal over the next 6 months is to make all of this significantly easier so that Especially if you're building a Next JS product, which most of our enterprise users are, frankly.

Most of it is Next JS.

You could combine them, and it'll be it'll be perfect. It'll one deployment, and everything goes live at the same time. And you don't have to worry about maintaining Thirty different services just for a web app. Right? So I think we went too far that way. And, you know, the web is a pendulum. It swings back and forth from complexity to simplicity

back. And, I think we're we're seeing it swing back to simplicity, and I'm a big fan of Dave. Yeah. So we built the new syntax website. We just just released it, and, Scott picked the whole stack of Sveltekit, and we have Prisma on the back end. And it's it's like so beautiful to be able to have like literally the front end and the back end are just 2 different files, that are are in the same folder and you can just query the data that you want and the types. I know we've talked about this so many times, but the fact that the types just Flow from the the server to the the back end functions that run when it's loading to the front end. It's just like, Man, like, here I was a couple years ago writing GraphQL types, like, 6 times.

You know, like, you write 1 for the front end, you write 1 for the back end, and, like, Holy smokes. Things are are much easier these days. Heartache. Heartache inducing.

I am right there with you. I've been dealing with that ever since headless Came about, like, my my studio did everything headless and, oh, man.

You have the schema validation. You have the GraphQL, Schema, you have the TypeScript interfaces and then the front end and the back end, and you gotta juggle 13,000 things.

It's hard. It's really hard. I had to pitch this to my customer or to my clients back in the day. Like, oh, just trust me. This is the best way to build things. And then meanwhile, I'm crying myself to sleep at night Trying to keep up with the complexity. Like, I just think it's time for a little bit more simplicity in our workflows.

Mhmm. But that's a big reason why we wanna move to Next. Js for the internal payload, architecture.

You could still combine it with SvelteKit on the front end easily.

But internally, I I was at the Next JS conference recently and gave a gave a talk on the big headless lie, and that kinda Talked a lot about what we're saying here, and there's some pretty compelling reasons for us to move to Next. Js.

Not only for simplicity, but also for the developer experience of working on payload apps. I think we're gonna have some big wins coming up. We're doing a we're doing the work right now, and it's going pretty well.

Server components. Like, when I first heard of them, I thought, you know, wait, are we just really trying to worry about 200 kilobytes of JavaScript? Meanwhile, Phones are getting faster. The Internet is getting faster. I'm serving megabytes of images to my user anyways, but But here I am worrying about 200 kilobytes saving 200 kilobytes of JavaScript. That feels weird.

But I think payload is the perfect use case for why Server components are very, very important, and that is to clearly differentiate the boundary between client and server code. And our proofs of concept so far as we're moving to Next. Js, we have a config. Right? The payload config is isomorphic. It's used on the server, and it's used in the client For the admin panel, we have to have it in both of those places, but you have to right now, you have to segment out all the server side code out of it before it gets bundled up by Webpack to send to the browser.

And that means, you know, you're using Stripe. You're using any any node API at all. That's gonna crash your client side bundle, so you have to get rid of that code. But server components are an elegant abstraction that literally let you clearly and Predictably, separate concerns as you need to. So as you drill down, you have server components, server components, server component, client component. But Whatever you pass in that client component needs to be safe, and it just makes sense.

And it's it's gone very well for us so far. I'm really excited about it. It's a lot of work. Yeah.

Beautiful.

I'm curious about this trend that I'm seeing in the CMS world. I'm curious what your thoughts are on it. So we've seen we had folks on from Builder. Io.

I was part of a board on specifically on Wix, And a lot of these CMS companies are trying to solve the problem of people want page builders, but developers want to write React components.

And we're starting to see a lot of this thing where You can give them their page builder. You write the react component, and then you sort of just like you associate a piece of data With that specific component. So you're like, all right, well, put a person in here, right? And then then that's associated with a person data type on the other end. And then you can sort of just drag and drop and click together those things. Do you have any thoughts on that sort of Making marketers and developers happy in this in a single run? Yeah.

Well, it goes back to simplicity again. Right? Like, We're kinda talking about utopia at the moment, and, I don't know that we need to connect our React components Directly to the API sources like that, like, connect them at the hip. And, also, I don't wanna pigeonhole people into using just React for the rest of time. Like, If I'm gonna double down and, like, make some type of visual editor, I don't wanna connect it too closely to React because a lot of our users, Especially on the open source side, are using Remix or SvelteKit or anything else like that. And, I mean, the whole paradigm of static rendering.

Like, none of that is applicable if you're statically rendering HTML and not using React components.

So I think That would kinda go against my roots if I was to too closely couple this visual editing paradigm with React specifically.

I do I'm very jealous of Builder. Io and the fact that they can do that well.

I'll tell you that.

But I think what we're working we're working on this now.

It's our our own personal visual editor. So it's kind of inspired by what Vercel has done, with that content source maps, and Sanity was involved in that as well.

But I don't wanna just stop at editing simple text strings. I wanna be able to edit uploads. I wanna be able to edit layouts. I wanna be able to edit relationships And full rich text with your own custom rich text elements. And being able to facilitate that level of editing visually on the front end Is it a great order of magnitude more complex than simply, like, content source maps? This is a text string and it's magical, so you hover over it and you can edit the sync simple text string. So what we're thinking of is a pattern of using HTML attributes actually to say, hey. This corresponds with a group from payload. Oh, okay. And then, like, we just use HTML attributes on the front end. So you can, like, decorate whatever front end framework you're using. You can decorate your HTML with data attributes that then correspond to the source, and you do this on an opt in basis as the engineer.

And you can do it in any front end language. So it could be Angular. You could just add these in, and then you add a simple payload script that say, hey. Am I logged into the payload API? If I am, great. Then download this React bundle, our components, and render it over top of your website. And then that's where we inject the customization.

And it is React, but it's not your your own front end doesn't have to be React. It's just HTML attributes that connect the dots.

That's the paradigm we're going after.

Again, another heavy lift that we have to figure out, but it's going well. It's

it's a lot of work. To give people context, I was I've been for the last week or so, I've been playing around with the specifically the, Payload example that has a store built into it. So I think that's a good example of like you have orders and items that are related to the orders. And I've built an online store. I've built that exact same thing many times, so it's kind of interesting to see how it was done. So one thing That I've I hit upon every now and then is.

When you're building like an app and you say, alright, I'm going to use payload, I got I got my my data in there. I have a nice admin back end. But then it comes time to your user is, like, logged in.

And there's always the question of like, do you let your app users also use that UI, or do you build A custom UI as as part of your your application.

Do you have any thoughts? Or are you even able to share, input between the 2 of them? Yeah. Absolutely.

A lot of our big user our big, like, case studies are apps where The payload admin panel is literally meant to be accessed by the end user. It is that is it.

The entirety of the admin UI responds dynamically to the access control that you define. So if there are collections that some Joe Blow doesn't have access us too. They simply will be completely omitted from the admin panel. And if that person logs in, they see something dramatically different than the super admin could see.

And The entirety of the payload admin UI is also white labeled, so you can change every single place that mentions payload. Any logo, The metadata and the the title of the page in your browser, everything can be white labeled, and you can theme to match your company's branding as well, All with CSS and custom components. So we see a lot of the time that people if the application Calls for it, you can definitely expose it to your end user, and they can be productive.

But if you're building a store or something that is meant to, like, have some customer facing aspect to it in your front end, then definitely that probably still needs to be built, on your own.

And, to bridge that gap, especially in the React world, in parallel to this move to Next. Js, We are building a full component library with every single component that the admin panel uses, and it'll have a full storybook that goes with it. So Our forms are super dynamic and very difficult to replicate, like an array field.

You probably built forms before that have, like, Arrays, and you have to manage the index with the form label and Yeah. Drag and drop. Filter. Yeah. Yep.

Conditional logic, like if a checkbox is checked show other fields. Building all that stuff yourself sucks, and it's a nightmare, and it's not It's not really fun. You don't wanna do that as an engineer. That's a waste of your time.

Awful. Yeah. So we're gonna try to expose our internal payload forms And all the components that go Fast. So you can use these components in your front end if you need to to replicate some of the structure in the payload admin panel, but skin them yourself.

And that's gonna come in conjunction with this move to Next. Js. So some of them will be clearly labeled as server components. Some will be labeled as client components, And, they'll all have a full suite of documentation. Hopefully, that gap will close.

That is That's what I want. Because, like, I want to be able to say, like, Welcome, Wes. And then have a little pencil icon beside Wes. Click it. Little form pops up right beside it. I can change my name. Hit save right there. You know, I don't have to go to the back end and find the setting where it has my name. I want to be able to put that right inside of my application. So That's super cool that that's on the on the list. That's up next. That's literally, the whole team is working on the component library and the Next JS move right now Among many other things, but those are the 2 big,

priorities for us. Mhmm. A lot of the questions that we get in Discord and on GitHub cushions. They're mostly related to getting rid of server side code and custom components for the admin panel and replicating that behavior on the front end. That's why our focus is squarely on these 2 topics right now. And I just you know, at the end of the day, I wanna make make it easier and more fulfilling to build Very good web apps. Like, don't worry about the small stuff that you have to do every time.

Worry about making it truly, like, unique and effective, And don't have to worry about the forms. Like, nothing is it's time to get that out of our way.

Yeah. I know. I just think about all the amount of time that I've spent building my own custom back ends even on the syntax site. Right? I mean, it's just Why? Why am I why am I doing this over and over again? Why am I spending the time on it? We've had things like WordPress forever that just automatically had that even Drupal had really great content editing features that I didn't have to create myself.

You so you also have, like, payload cloud, which is the the product. Right? It's the the non open source version of this thing. Well, it's the the non Free run yourself version of this thing.

And this specifically is just a hosted data platform for the data to make it easy So you don't have to run this in your site. Is that correct? Yeah. It's,

I mean, you could deploy payload on Vercel, but then you have to bring your own database and then your own s three bucket and your own email provider and then Wire all that stuff up together, and by all means, you can do that.

But payload, you just it works just like for cell where you connect your GitHub repo and then you push Deploy, and everything gets given to you on a silver platter. So it's just easier. And by the end of the day, like, you might save a little bit of money if you wanna go provision all that infrastructure yourself, But we don't mark it up that much, and, payload cloud is not really the main revenue driver for us. It's not really our long term goal. Mhmm. It's more like, Hey. If you're a junior developer and you wanna get up and running with payload quickly, this is probably a good bet. Or if you're building a website as an agency and you don't wanna manage the infrastructure, Go for it.

But I think really where we've seen payload shining is in enterprise context Where there's a significant workload, and they need very explicit features like a Salesforce connector or Publication workflows to say these 6 people that came in from Azure AD can only save drafts. They can't publish. And when they do save a draft, they have to submit it for review first. Then that goes off and it triggers an email, and somebody else has to log in and review it. You see what I'm saying? Like, there's a whole There's a whole ecosystem of very significant enterprise only features that we will sell to large companies, and We'll charge the large companies, but we want people to be able to use payload for free. And so payload cloud is basically just a lower barrier of entry. Okay. And with payload cloud, let's say you were hosting a front end.

Is it is it possible to host your front end? Let's say, this SvelteKit version of our our UI onto the the site with The data itself? All of our boilerplates come with front ends, actually. So with that ecommerce one that Wes was mentioning Cool. That's a Next. Js Storefront and one click, you get your whole Next. Js website and your CMS from the same repo all running on payload cloud. It is a server, so it's not serverless. I guess that's debatable. I think people even call, like, AWS Fargate serverless nowadays.

I don't even understand any of that. Yeah. Who even knows? Yeah. The line's a bit blurred. Yeah. But, yeah, you can combine them. That's that's really interesting. And, like, We've been talking, like, a long time about, like like, why does JavaScript not have what Laravel has? You know, like like Laravel has Laravel, But then there's they have like Laravel Spark. If you want to whip up a $9 a month SAS product, you throw Laravel Spark in there and all of a sudden you have a you literally have a business, you know, and there's Laravel Forge, which is probably similar to your hosting solution. You know, you can, use it to host your application. There's Laravel Nova, which is a bit of admin UI.

So, like, Do you have any thoughts like why have we not had that? Like the other thing people say is, where's the rails for For JavaScript, is that what you're you're trying to build here? Yeah. Exactly. That's exactly right.

I used to use Laravel Forge, Nova, Spark, all of those. Okay.

You nailed it.

Mhmm. Yeah. We built some significant SaaS products that were all built on Laravel back in the day.

I think it's just a side effect of the how split the JavaScript community is, And there's so many different ways to do anything, and it's overwhelming. But, like, with with Ruby, you're gonna go with Rails. You know, it's just the de facto standard.

I don't really I'm not really jealous of those other programming languages that have 1 pillar. I think it's good to have variety.

But, I do think that TypeScript needs something similar.

And there are good options like Redwood, for example, They get you the back end, and they have a nice pattern for building an application framework. And there are good options out there. None of them have truly taken over.

But to me, The admin panel is a crucial aspect of all of this. And if it can work cohesively across not only the endpoints and the Graph and access control, but also a full admin UI that's generated without any effort at all but can still be customized. That's like my Goldilocks zone.

And I have to kinda blaze that trail myself. And that that's what we're working towards, 100%. That's why I wanna drop the CMS.

I almost think CMS is a stigma for us. Like Yeah. I I I I bought the domain. Some logistics trucking company owns payload.com.

I'm gonna send that guy a message.

There are so many parallels to Silicon Valley, the show, to our reality. Like, there's this there's an episode in that show where they had to buy piedpiper.com or something from the from the guy. That's gonna happen to me in, like, a week. So cool. But, Yeah. I I wanna broaden our horizons a bit. That's great. I I love it, man. Like, I'm I'm really excited about this. Just thinking about,

I think about how amazing headless components are that they give you the accessibility.

But, like, imagine you take that 1 step further, and it also includes the logic For updating and validating and all of that, such a pain in the butt type stuff that that comes along with building these apps. Right.

We'll see. There's a lot of work, and we're a small team. But Yeah. Luckily, our open source community is pretty pretty awesome. Discord is Pretty rowdy in there. I'm you guys are no strangers to that.

It's it's hard to keep up with. And oftentimes, like, you know, we are open source and We are venture backed as well. I am going to try to produce revenue from larger companies like I mentioned, so I'm not gonna do payload micro transactions Ideally.

But it you know, building an open source company, it's it's a challenge. You know, it's, you have instant exposure and instant adoption, and then you gotta keep up with it with a small team.

And you gotta prove that people like it, and then you gotta figure out how to monetize it. So, I think we're do I think we're on the right track. It's a pretty exciting time for us, but Lots of work ahead for sure. How is the process of going open source

and having to manage, Perhaps contributions. Right? Because contributions are great, but everybody kinda has their own idea about how things should work and where things should be. How how do you manage Having a a community being open source and then also providing

the explicit path and direction for this thing to go. That's a moving target. We have to get better at that. I will be the 1st to admit.

Oftentimes, our road map is quite well defined from our users, and they ask for things and then we try to deliver them, but then you have some wizard out of left field. Like, for example, there's 2 2 scenarios where I can mention. Mhmm. Number 1 was Server side hot module reload. So, like, every time you change an endpoint, instead of restarting the server with Node mon out of 2014, You just dynamically remount the the endpoint or something. And some one of our community members, THGH, just came in and built that for us, gave it to us. And, same thing with Veeet support.

Like, we, in two point o, we added Veeet support, and he just came in, same guy, built it, gave it to us. And, you know, it wasn't fully functional, but it was a proof of concept, and then we were able to take that and, bring it across the finish line with him.

So it's collaborative.

We don't really expect PRs to be fully, like, yes, you literally wrote every single line of code that we wanted you to. It's more like It's a collaboration, so it goes back and forth and we try to work together. I still don't think that the GitHub experience of contributing and, like, maintaining and I don't even know how that works. Somebody forks payload, we can commit to their branch. How does that work? I have a idea. Turn that on. I always have Turn that on to my repost because it's like, oh, thanks. But there's just like 1 thing.

Can you change it? And it's like, no. Let me just jump in here for 2 seconds and make a quick commit to to make it how I want it, and then we'll deploy this thing. I have no idea how that works to this day.

It's GitHub black magic. Yeah. And and, frankly, every time I have to do it, I ask one of my team teammates like, hey, guys. Please help me. I'm old. Help me figure this out. It's probably It's probably AI according to to GitHub these days. Did did you see that? GitHub is is redefining

their entire company on AI. It's kind of Scary to me. They like they said just as we built the company around Git, we are now, like, building the company around AI. Interesting.

If you ask me, GitHub is one of the best, like, things that I use. I don't really know what I need more out of it.

Maybe they can show me things that I didn't know that I needed, but that's, like, consumerism at its finest, I guess. I don't know. What what would they do with it? Does anybody know? Like I I think it's just about, like, There's a lot of like slog

in using GitHub and just making that slog easier. At the very least, it's AI pull requests, you know, or AI release notes, rather than having to make sure everybody writes their commits in the exact same way or when someone sends a poll request. All right, now I got to spend 30 minutes describing what this has done.

Can you review what I changed and maybe summarize that or least get me 80% of the way there so I can, move it a little further. I'm sold. I haven't heard about this, but I will be a happy consumer if they At that, if they can write my release notes for me and it's actually good. Yeah. It's called Copilot for pull requests. I've been part of the I don't know where it's at right now. I've been part of, like, all of the, GitHub Copilot testing things.

And then they they sent an email the other day how they're they're wrapping up a lot of the the Copilot lab stuff, And that's it's moving

full go into Mhmm. Into GitHub now. For for me, we're adding some AI features into payload, But I don't wanna live in a world where content is fully written by like, content that you read on the Internet. I don't wanna read robot content that's regurgitated.

Like Totally. It's gonna have to be a balance for us, like, how to I don't even know the word to use, like, responsibly allow for this. Like, Not that, like, ever a large percentage of the Internet will be powered by payload, but I don't wanna read blog posts that are regurgitated and written by Peter, ever. Oh, yeah. People are doing that like crazy right now, but that will not work. As soon as that becomes table stakes,

As soon as anybody can create a whole bunch of barfed out content, it's not going to work anymore because there's gonna be more content than anyone could ever read. And it's It's just you're not gonna say, wow, this is a great article. It's like, oh, good.

You just have 20,000 articles on types versus interfaces Out there and they're all Yep. Kinda doing the same thing. I think that

as a humans, we're gonna just adjust to the type of things that we pay attention to. Agreed. I really hope that's true. Well, it will be true for sure. I describe these AI features as table stakes. Like, even when I'm talking to and stuff. I'm like, yeah. We can add these AI features, but they are literal table stakes. Like, this is this is not a thing that will produce, Like revenue for payload. You and and, you know, a lot of the good thing about, like, the VC world is that a lot of them know that already. They're like, Oh, well, we wanna invest in AI stuff.

Yeah. But you guys actually have a product that you've built, and it's got a lot of features, and you've Actually written a lot of code here. It's a little bit more than just a writing assistant. Right? Like so it feels like the the tide is moving a little bit there.

We'll see. When I go to raise the series a, we'll let we'll let

you

know. Yeah. Yeah. We would we will give you a truckload of money if you add these following AI features. Sold. Gotcha. So is that is that what you have to do now, go out and and raise a bunch of money from from people? No. We don't have to at all. We're good.

I think that financially, Payload is in great shape. We have some big names. I think one I can say is Microsoft has been an enterprise customer for over a year, actually.

So, we have some big names and some other very likely potential partnerships soon, And we're good. We don't need to raise. I think the question would be if it's working and we wanna Double our team so that we can keep up with these CMSs that have thousands of employees Yeah. Then maybe we need to. But, you know, I I like the Looking at the world and, like, okay, PHP has Laravel, Ruby has Rails, where is the TypeScript equivalent? And I really do wanna fulfill that vision.

And, to do that will probably require some more employees. So we're we're we're likely going to look for funding,

next year at some point. I saw There is a Sentry and payload plug in. It just seamlessly integrates. So I thought this is the perfect little Transition that we can use.

So if you want to throw Sentry in your payload, to get performance monitoring and error tracking in your application, Just there's a integration for it. You just throw your API key at it, and you are off and running. So I don't know if if you guys built that or Sentry built that, but thought that was pretty cool. We did. And,

over the weekend, I used Sentry significantly for the first time In my life, like, we've had it running. We've been a Century customer for our own products for years.

But it's mostly been on the back end where, like, You just see the the errors that happen, and it's I've always been kind of a surface level user. My team gets into it heavily much more so than me. But For the 1st time this weekend, I logged in, and I was literally blown away. I didn't know it could do I'm not really trying to, like, Help you guys Yeah. I know. Let's hear it. Sent you. Doing that. Yeah.

Yeah. Let's keep going. I I didn't know it could show, like, the network panel, or I didn't know it could show the console Or, like, the timeline scrubbing of the different, like,

replays. The timeline scrubbing is unbelievable. Yeah. I I had no idea.

So big fan for me, For sure. It helped us figure out the bug this weekend. There was a bug with payload cloud and we saw Oh, really? Because of centuries, literally. What what what was the bug? Are you Able to tell us? I was, like, hearing these stories. It was a missing question mark. Optional chain up. Literally.

Yeah. One question mark was missing, and we had to scot it down. And, you know, the error from the user was, like, super abstract. Like, something went wrong, and I don't know what happened. And here's the console log, and, like, we had no idea what that meant. So fired up Sentry, found the air, Ran with it. Shit fix. Yeah. We had that with the the syntax website. We could not figure it out. And then I just watched the the session replay,

and you could see what the user was doing, and I just went and did that. And I go, oh, I see it. Yeah. Awesome. Alright. Let let's move into, The supper club questions. Real quick. These are questions we ask everyone who comes on. We're curious what laptop And keyboard you're using? Well,

I am a minimalist.

I don't buy anything ever, and I Have an M1 laptop, which changed my life. This thing has I can't believe how much better So much better. MacBook Pros got, Like, holy lord.

But I just use an Apple keyboard and some Razer gaming mouse. That's it. I'm surrounded by mechanical keyboards here that I like, I'm deafened by the sound of them clicking.

Maybe someday I'll get on that train, but I like this, The symmetry of typing on my laptop and then going to a keyboard, that's the same.

Yeah. So I just stick in that ecosystem. Exactly the same here. I can't except The the major upgrade I recently got was the the new one that has touch ID in it. You don't have to reach reach over to touch ID. It's

Big big upgrade. Are are you in your office right now? So this office is in Michigan. It's, I built I bought it from my agency, actually, back in, like, 2020. I started the process, And then COVID happened and construction doubled in price and cost and everything. So it took us a long time to finish it. We it's still not done.

But this is the office, and it's, gonna be home base. 10 out of the 12 employees that work at Payload are here in Grand Rapids, Michigan, and then 2 are in Europe. But, and you you go crank some be like the club. Founders after work then? Oh, yeah. Absolute well, you know what? Founders kinda screws me up. Oh, yeah? Yeah. The founders. Yeah. It gets me good. We we drink go to hop cab. Yeah. Exactly. We we stick with Malort around here, which Oh, yeah. I know Malort. Yeah. My my brother lives in Chicago, and he's a

he's a big Malord fan. In fact, their their dog is named after Malord. He's not named Malord. He's named Jepsen, but, Yeah. That's how you know you're from Chicago.

Absolutely.

I I spent my twenties there, and, funny story about Millard quickly. Like, There's this guy that grew up in Chicago. He's one of my best buddies, and, I'm on a chairlift with him. We're snowboarding, and he pulls out this flask. And this is like 2014.

And he's like, hey, man. You want a little nip? And he hands me this flask, and I'm like, sure, man. Yeah. Whatever. And so I just try it. I'm like, He was drinking it unironically.

Like, you know, you normally drink Malort to, like, be a weirdo, but he just had it. He was just drinking it full Chicago native mode. And I tried it and, like, Tim, what are you doing to me right now? What is But now now I'm in. I'm here for it. Sudden quiet taste.

What about if you had to start coding from scratch today, like, what kind of thing would you attempt to probably do TypeScript again.

Start with the front end. I think the complexity has almost shifted from back end to front end nowadays, and I would definitely Follow a similar trajectory to what I had done in my twenties.

Learn the front end. Learn how to translate, like a Mach to a working prototype and then figure out how to connect it on the back end later. But, I'd start with TypeScript, and I would Try not to get intimidated by the amount there is to learn.

That's what really got me in my in my younger years is, like, Every time you go on Stack Overflow or wherever, you just get overwhelmed by new words that you've never seen in your life, and everyone is a scientist. And are you stupid? No. Like, they're just they've been doing it for longer, and it takes a while. So you gotta, like, pace yourself, you know? I'd I'd go for the front end again. Is there anything you are excited about in the Future of web development.

Besides payload, obviously, taking over and becoming the rails of JavaScript. I would like to see the bundler ecosystem be solved once and for all. And I would like to see the gap between ESM and common JS close, and just anything with all of that whole paradigm of node engineering just to be solved.

Whenever that happens, I think all of our lives will get much easier, and that's the number one thing that I struggle with nowadays. Beautiful. I like it. Alright. So last thing we have here is a Thick pick and a shameless plug. Do you have anything for us today?

Investors like GitHub stars more than we do. So if you wanna come check out Payload and get us a get upstart? The investors will be happy, and it'll help us. But that's it. That's all I need.

Awesome. Thanks so much for coming on. Appreciate all your time. Thank you. Thanks for having me. Thanks, James.

Head on over to Syntax dotfm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player or drop a review if you like this show.