The Big Headless CMS Lie (James Mikrut)

not going to lie I'm pretty pumped up to be here right now Geo had a slide with the payload logo on it and that makes me feel very special um but yeah I'm uh I'm James I'm half designer half developer and um I've been building big digital products for I don't know like 10 years I'm getting old um but today I'm going to talk about the big headless CMS lie I am a headless CMS that's what my company does um but I've learn learned a lot over these past couple years since this idea came out and uh I'm going to try to transition that lie into something actually what I think is my personal Utopia um so fun fact back in the day I actually built my own server side rendered react framework when nextjs was still on the um the pages router obviously but it didn't even have Dynamic route slugs yet I don't even know what the technical name is for that but it was in the early days so I built my own and um yeah it nextjs had a glow up and uh they made mine look like a kids toy so good job next you win you win that round um anyway so I've been pedalling headless websites for quite some time when I say that I kind of feel like a drug dealer you want to buy some websites like I it's a little strange but um I've been doing it for a long time I've built like native apps and everything this one was on my own uh SSR stack we home rolled it it's still live I'm still like pretty happy with how this one turned out um but it it was just headless WordPress at the time and then we did um Claro's corporate website that one was on nextjs so like it was getting easier um building massive Enterprise websites was becoming um maintainable and effective and efficient but it was still powered by WordPress um and then I started building like actual native apps and big projects this was one that we built with payload actually it's a native app but payload handles all the off and all the back end and the stripe and everything like that that one was pretty fun things were getting a little better um but every time I pitched this stuff to my clients at my agency I would like I would tell the biggest story I'd be like oh you're going to love it separation of concerns the back end is separate from the front end this is how it should be done and I just go to town just preaching to them Omni Channel content you can use content across many different apps like headless CMS like it's all API based and the dream is like one Central source of content right um migration is easier because if you want to change cms's you don't have to rebuild everything you just rebuild the back end same thing with the front end you go through a Rebrand you redesign the front end but you don't have to change your CMS um those are all real quotes I actually said all that in my youth when I was you know trying to get clients and I will literally say anything to get money so um but did anybody ever care about this stuff like my clients did anyone a single one of them ever care about any of this no they did not at all 0% um did separation of concerns ever really make my job easier as a developer no how often did anyone actually use that single source of content across different projects literally never not once um did they suffer with broken preview every single time this is like I don't know if anyone has wired up WordPress preview with a headless website it is not fun it is my tragedy it's like just my downfall um and did they always hate the extra devops like deploy the CMS deploy the front end make sure that your your future uh features are deployed in parallel like there's a lot of Heartache that goes into that and we always hated it um and did we ever get tired of wiring up the same thing over and over again especially in an agency setting every website needs redirects every website needs metadata every website needs forms every website needs the same things over and over again and it got like monotonous to be frank um I'm old I'm tired of of it I want something better and um it doesn't have to be this hard as Engineers I think we do this to ourselves a little bit I mean the the end result always is a great website that's because of nextjs and that's the reason why I was pitching so hard for so many years to go to headless because I wanted to just use nextjs so that's the big lie like I pitched this stuff for years and if I could have just told him hey I just want to use xjs in the front end that's like the real reason there um you know there's there's a time and place for all of those um benefits and if you're Bloomberg yeah you might want like a composable cloud and all this stuff but like nine times out of 10 they didn't know what I was talking about they didn't care um yeah and that's the lie so you know there's a million headless cms's out there you pick your poison a lot of them are pretty good um a lot of them are here today and I respect all of them um but I just want to build next stuff and I'm going to tell you a little bit about my personal dreams my Utopia this is something that I've thought of for years doesn't have anything to do with Windows um nowadays I just use Windows for Counter Strike but um that's about it so number one I need to get out of microservice as hell that's a real thing for me like I don't want to go sign up for a thousand different vendors just for a website like that feels strange to me I'm kind of done with it um I want a combined CMS and a front end I want to deploy everything with one server this is like weird like reminiscent of traditional cms's I don't know how many of you are familiar with like headless versus traditional doesn't matter but um I want them combined again so that when I deploy a new feature I don't have to sync changes from the CMS and the front end at the same time I want to deploy on verell I just want to have it deploy when I push code have it build fast and have it get on the internet and then be able to roll back and all that stuff and bonus points if I could get all the boring stuff out of the box for for free so that I don't have to manually wire up metadata and redirects and rewrites and all this stuff I mean that's good that nextjs provides that but it should be easier it should be almost automated to be able to get all this stuff out of the box um I just want Simplicity and Geo mentioned that this morning and I think that's like critical you know like when I when I first got like bought into the nextjs ecosystem it was because it just worked you didn't have to learn a lot you just you jump in you figure it out you go to town you do your thing you get paid you go home and uh that's what I want right now there's a lot of friction between cms's and websites and it's kind of like navigating a maze of baloney and uh I just want to restore a little bit of love back in the equation like um if we connect these two things are we still talking about headless is that word even relevant anymore if you're building something that that doesn't have an API like what year is it what are you doing headless is implied at this point there is not a big difference between headless cms's and traditional cms's even WordPress has a rest API and lots of graphql plugins and everything I mean payload will always be API first no matter what but um and it could work with any front end but I just want to restore a little bit of that love there so how do we get there um I run a headless CMS I think about this every single day many of you are getting on the AI train and you know I'm admittedly a little bit behind in that because I still write typescript like for my product but um yeah I uh payload is cool like I'm pretty proud of it we're a little seed Stage Company and we uh we've got some big clients we're making magic and um it's got a lot of nice stuff live preview we're MIT we're open source we're not another SAS app that you have to sign up for pay a subscription for um and you can extend the hell out of it it's all completely composable and extendable um but you still have to deploy two separate things we're an Express server so we have a vanilla react app we have an Express server and you have to deploy those two things separately and it's not um it's not like my Utopia yet um but payload is very modular and our at the like Bare Bones of it we have a local API which is what I call like the way to go directly to your database there's no HTTP layer here it's not a rest API it's not um graphql you hit your database directly it's almost like an OM and um we actually exposed the orm that we use to you uh we just added postgress support with Drizzle drizzle is fantastic by the way um I really really respect that team they're doing God's work um but this local API is portable and it can run anywhere um so what if we could ditch Express what if we could leverage the app router get rid of Express open up all of our API endpoints as uh route handlers and just like write a small thin abstraction over top of nextjs and build payload into nextjs I think there's a lot of potential there and we could completely eliminate the need for deploying two separate services for a website like this is a website we're talking about you can get more uh like extensible and more like separated if you want always you can always do that but we could ridiculously simplify and that's my personal goal um just imagine it like one repo you've got your your website you've got your custom route handlers and you've got all the payload stuff just sitting next to it in the same repo you could share code Type safety from end to end but um before I go any further I just want to talk about like we have some gratitude to owe the nextjs team they do a lot of hard stuff and I used to try to do this hard stuff with my homegrown like monstrosity but um webpack is hard turbo pack 10 times harder I can only imagine serers side rendering static rendering on an opt-in basis um redirects rewrites middleware everything is out of the box it's got all the bones that we need and they take care of it for us and that's very complex if you ever think about all the webpack magic that happens behind the scenes like every one of your functions is being bundled separately for a separate serverless function and that is very difficult I'm just very grateful for all that work that they do and right now I'm going to air some of my dirty laundry uh on the technical side going to talk about some of the things that payload has to solve in the coming months first first up this is like my personal least favorite thing with payload the payload config is um isomorphic which means that it's used on the server and it's used in the browser and you write serers side code in the payload config and you write custom react components for the admin panel but it's the same file and to get rid of the server side code so that it doesn't blow up the webpack Gods uh we have to use webpack aliases and that is basically like hey if you see this import don't actually import that server code import this mock file instead and this is a pain in my ass um it's not fun all the plugins have to wire up their own aliases and bundling is very difficult and if I had my way we would just completely remove this from being a necessity oh wait a second nextjs solved this with server components um that's what they're for at like first glance you might think like why are we trying to save a couple hundred kilobytes of JavaScript like that's not that big of a deal I'm going to serve a 10 megabyte video to my user but that's not the point the point is a clear separation of client and server and that's a hard thing to do so we're going to try to solve this problem on our own but nextjs already solved it with react and it's a perfect pattern um I personally am very very tired of the bundler ecosystem we just released 2.0 we added uh vit support and vit is impressive but I don't think it's the like the end all be all if you want to cry with your browser look at your network panel when you load up a v app just watch the requests pour in and in production it uses a different stack and now I got to manage webpack and V and I'm just tired of it I don't think we have like the the end state in sight maybe we do with the nextjs compiler though because wait a second I can just offload all of that to nextjs and then I could actually focus on my product which is a pretty wild thought to me um last thing on like what we're trying to solve right now we use noon which is a relic from 2014 um and uh it restarts the server every time you make a change right um but that's not serers side hot module reloading that's like the full thing restarts and then it reinitializes reconnects to the database um we want to solve that more gracefully could we do it yeah we could we could monitor files for changes and then rebuild the models and do all the stuff uh but wait a second that was already solved by nextjs we would get that for free out of the box um honestly I think think that payload is a perfect case study of like a real world example about why all of this stuff matters and you know you might not need all this complexity if you're just building a portfolio website but I can tell you from Deep pain that all of those things that we're trying to solve are very hard but nextjs already did it and that's why this is why um we are an isomorphic app I'm tired of webpack gymnastics this is new but it's sorely needed if I ditched Express and I went to the app router payload would instantly get significantly better we could make some magic happen we could optimize the developer experience I'm a huge proponent of Simplicity I want to get things done fast I want to be proud of the code that I write I want it to be clean and this could optimize that we could separate the server and the client it would be a logical boundary that's well defined and semantic we could make devops easier we we could give a head back to the Headless CMS optionally you know if you want to use Astro or if you want to use spelt kit you could still do that with payload but if we move to nextjs it would just be seamless and you know what a lot of my customers are building with nextjs anyways um endtoend type safety payload is typescript we generate types for you very strongly typed um everything and you can reuse those types in your front end so imagine for your re react components all of the props for the content models inside of the CMS you you don't have to write those types yourself they're just given to you and you could have end to end out out of the box so what about other Frameworks like am I going too hard I'm a headless CMS and I can't like you know people like headless like I said because you want to pick your front end of choice but um this would still be possible we're always going to be API first you could still deploy as an Express app if you wanted to because the nextjs custom server completely supports that we use that all the time with payload because we are an Express app so that's not going to change and over time we could add more connectivity like handling redirects and handling metadata and all that stuff for other Frameworks out of the box so I want to be clear like I don't think that if we move to nextjs this would be a bad thing for other Frameworks I think everyone would unanimously benefit from this um the cool thing selfishly for me is that I would be able to concentrate on the things that make us great and nextjs as they improve we just get all that for free and I don't have to do a damn thing and that sounds really nice I might be kind of lazy I'm not sure um cool thing number two is that if you do use nextjs for your front end your life is going to get way easier immediately you can simplify you can have like the most beautiful codebase imaginable and you don't have to go to a SAS vendor for another separate service you just get it it's free um so what are the drawbacks like I'm I'm on this kick right now of like relation databases versus non- relational and I see benefits on both sides and in Tech nothing is ever like a universally good idea or a good decision you have to make decisions based on your problem um but I think the biggest one would be that we just released 2.0 so this would come with breaking changes um and the express style connect middleware would not be um compatible because the app router has the um browser or the I don't know what you would call it the request response that's like native and there's no Express magic there and uh oh esm I depending on who you are you might like this but I think we should probably move to esm if we do this and pull the bandaid off and like you know I'm I don't want to talk about that anymore so uh next needs a proper headless CMS it needs a native next CMS and my question today is should we be it um should we make the jump and should we refactor and go hard on the app folder and uh Embrace serverless components and um I want to hear from you I want to hear from our community for those of you that are coming from our Discord and everything watching this um I'd love to see if you can vote on this um we are open source Community is everything to my entire company it's crazy how helpful they all are the PRS that we get blow my mind every single day someone will come in build a massive feature and just hand it to us on a silver platter and so I need Buy in on this one I need people's opinions I need some I need to beat up this idea we're not going to take it um lightly but I personally think it's only going to benefit everyone um so if you can vote on this poll that would be great and um I want your feedback in general we are a new company um I'm big on this ecosystem and uh I don't get out there much with my opinions but um I want to hear from you and I would appreciate any thoughts you have and I have two minutes left wow thank [Applause] you

Channel: Vercel

Views: 36,255

Keywords:

Id: jCMU4qw6LqI

Length: 18min 14sec (1094 seconds)

Published: Fri Nov 03 2023