Composable CMS evaluation: Delivery APIs and CDNs

hello and welcome to another discussion of composable cms's and how to evaluate and buy them and with me as before is uh Tim bennox and hello hello everybody and today we're going to be talking about uh content Management Systems uh apis cdns Cloud hosting Edge personalization all that fun stuff so it's it's really all of the things that you need to know for uh getting content in and out of your content management system and so we'll talk today about a few things uh first let's talk about apis and I know Tim you are very opinionated on the subject of apis I love it because every episode you ex you introduce me in a team you're pretty opinionated on this one I'm like yep and say yes on all of them it's a polite way of saying Dutch maybe you're very Dutch perhaps um maybe before we dive in um people can actually scan this QR code or follow the link below to download our CMS guide on how to evaluate them and so this is one of those places where it's all nicely structured and then in these streams we grab a little piece of that and then we just have a lovely discussion and in this case a lot of Team opinion apparently I like it yes exactly thank you for remembering to do that we've done enough these things that I keep forgetting the intro well it's these ctas that we have to put in right yes yeah that's true um okay so let's see first let's let's talk at a high level um about the apis that we're going to be talking about and I've I've categorized a couple here but even as we were discussing this beforehand you said there might be more of these and I I sort of noted typically content Management Systems have two or more types of apis but usually they'll have these two and those are content management apis sometimes you'll see them referred to as a CM API and content delivery apis and I think this is a really important distinction because when people are talking about performance and uptime and content delivery networks they're almost always talking about content delivery and the funny thing is if people are running into performance issues with headless cms's all it's almost always with a Content management API and a Content management API is really an API that you'll use to create update content import content and and often a Content management API um by necessity will be slower because what's happening is you're getting that content you're you know adding those things you're putting them into a database and it's it's a much more live Dynamic API um and you usually can't do a lot of the performance enhancing things like caching and content delivery networks that you can with content delivery apis and so you know often there's there's a real disconnect in performance there and so it's it's something that people need to be aware of that if your use case means that your composable content management system um is connecting deep with other systems and other systems are writing content to your CMS system or you're doing a bulk import of content the performance and the performance bottlenecks on that content management API may be fairly important and so that's I want to get that out of the way first and then uh talk a little bit about content delivery apis and then Tim you also mentioned that a lot of cms's also have a few other apis potentially related to content rendering and delivery well yeah there's sometimes these differences especially when it comes to the graphql endpoints where of course graphql when you do a query like that you always or most of the time because there are some other options but you have to do a post and a post you cannot cache locally right so you have to do a post and then get that data back and by Nature these apis are super Dynamic so suddenly you have a CD a Content delivery API that is super dynamic because whatever Fields you want it has to Output that right so there's an extra complexity layer there and you see that certainty um uh CMS then have like okay this is a hyper cache version of whatever we do there and so it's more stuck to like a TTL or something like that and then there's a normal one and then I've also seen where some of the CM date endpoints so the content management ones are maybe less important because they just get hit less but then you like I've had to do it recently where I had to import like 200 items into a CMS and I needed to do like a 1200 millisecond timeout between requests to be able to even not bottleneck the whole thing and so the more Enterprise you go the more important these CM endpoints become right is management stuff yeah I think that's a really key Point um and if you're if your content management system use case dictates that you're simply using their web application to create content and that's all you're ever going to do you may not use the content management API at all um you know similar time it doesn't exist yeah it only exists partly and I've had it so often that we are speaking to some CMS vendors and then I needed to do something with an import or a change and then like yeah we have this internal API but it's not open maybe you can hack it like sure I'll hack it let me just grab Bozeman in my session token and see and it's kind of funny how often that happens yeah no absolutely I think we're we're sort of talking about this as it's as we think it's it's table Stakes but in a lot of cases it's not and you know to your point depending upon how enterprisingly the CMS is it may not have those apis at all um you know what else within that I think it it also sometimes you get some interesting uh cases where if you are working with a Content management API and you're writing to that API and then you're querying from that content delivery API there's often a delay because what will happen is you know you'll you'll save that that content gets sent to the CDN and then it's the CDN that's serving up the content and and that's not immediate and so sometimes if you're writing an Enterprise application that's some external system that's writing to that content management system API if you're if you're then sort of continuing to work with that asset in a lot of ways you need to continue to work with the content management API because you can't depend upon that asset or that content item actually have being pushed to the content delivery I have to be honest I have not experienced that in about five years I think in a certain system where you would hosted yourself that we both know what we talk about that we won't mention um that happened all the time and we would do our whole development uat and QA phase just on this CM server that was also able to deliver some stuff but just slower yeah because you just it was just too much stuff to sing and all that but nowadays when everything is in the cloud especially with the more Cloud native cms's that have a great CDN in front adding stuff into the CDN is almost run time and almost per field so I haven't had that issue in a while but I guess when you grow and go more enterprising you have more different things that are syncing suddenly the syncing as fact that takes time becomes very important yeah no absolutely um let's see here so I think we've we've kind of exhausted everything people should know about content management apis uh let's talk a little bit about content delivery apis and particularly uh cdns so I think this is one of the um interesting areas of differentiation for some vendors as well and I think it is one of those things that you need to evaluate closely to understand what your what Your need is um because cdns are expensive um and you know you as a client will be paying for that capability and if you don't necessarily need it for a particular geography or a particular performance or even if you're using your content management system for static rendering you may not need a CDN at all so let's let's discuss some of those issues well again I haven't actually seen at least in my personal projects any issues with that I it's now it's that good with the SAS CMS providers I guess almost all of them that it's so good that I don't even consider hey is this on a CDN or not because the response is always quite fast however I've been learning more and more recently of course we'll talk about that later a bit when we talk about netlify and for sale that things are now not always static rendering anymore the gem stack is kind of it still exists but it's there's many more flavors now where you can do um server-side rendering with a caching layer in front that sometimes might query and other times it might not and then I've now noticed when you hit a certain CDN that's that for us an API endpoint but you do it through maybe a CDN Edge Handler on for sale from France that round trip actually takes pretty long even though the C this the the API and the CDN from the fender is really fast and so we have now exploded in options where things can go wrong or go right and where let's say a year ago where we most of us did like all these SSR type or SSG type projects I haven't even thought about performance right and then the thing is that's quite funny when you're done on a local development State you don't do static rendering it's it's all like completely dynamic because you're locally developing and then some CMS has surprised you by how fast their API responses are and then others you're like oh this I did not expect this at all I won't name names here because it's not worth it there's a whole CMS evaluation guide where you can find everything but it's it's really interesting to see and that you're pleasantly surprised that suddenly your local development setup is really fast and that's just because these endpoints are super super fast and so I guess it's just cms's need to know their target audience how they build projects and then just deliver the features that they require based on slas and whatever feature requests and it's it's right now it's a bit of a wild west and yeah I'm pretty excited about it to be fair yeah no there's there's a lot of options and a lot of differentiation here I think this is this is one of those areas where I I think and this is my opinion we're seeing most of the differentiation um you know obviously there's some other areas of differentiation but it usually tends to be this I think what happens is uh you know some agency or you know some company will be looking at some CD or some CMS and be like oh it would be nice if some of the API Behavior did this a little bit differently and then they go off and invent another CMS um oh I've seen many of those yeah I love it exactly I'm probably all frontend devs that were a little bit like leaning back back end like me we've all built our own CMS before and then just trusted there for one project but still yeah uh let's see here another area of differentiation for Content delivery is uh preview apis oh yeah like but that's just draft State I imagine of a certain item right yeah but I I think that's important to note um sometimes you'll have three states of an item right you'll have that that original copy and then you will have something that's work in progress so you know you're making changes but you're not necessarily committing that version you know back to that system and you're not necessarily publishing yet but you still want to preview it um and so often cms's will have a preview API capability um and and again this one is is interesting and and may be uh fairly complex and you may need to dig into the details because that preview API when you're calling it you may be previewing that that the single item that you're working on but if that preview also has components that are working with other items the state of those other items may be served from um you know either like that content delivered version or a Content management version so sometimes yeah if you get you're crazy yeah sometimes you get weird sync States um depending upon where those other items are and this is I think one of the Hidden complexities again of of headless systems certainly relative to uh digital experience platforms I know you know when we're using sitecore when you were previewing something in the context of a page there was a lot of capabilities around saying okay it would actually know the state of all those items you could rewind the clock to say okay what do all these items look like at a certain point in the past or what do all these items look like at a certain point in the future um and that was some really very useful and Powerful preview capability um yeah I think sitecore that we have to give them props here that's amazing like they're component based data templates and versioning and then smart publish and publish everything or publish a group and then go back in time that stuff is unrivaled and right now when when I use different headless cms's you can see they're all trying to tackle this issue in slightly different ways and then sometimes when you hit publish you get a little pop-up that says there's a few items in draft do you now just want to publish all of them and then others don't do that you go and preview your page and then suddenly this image is not showing up because they don't have that workflow or you cannot customize that workflow and then in your API you might not get something back and you just don't know why yeah exactly so yeah I think it's really important to point out because this is one of those areas that especially for folks coming from cms's like you know Drupal Aquia sitecore a lot of that capability because because they're monolithic that's actually one of the benefits of a monolithic system you you have context and understanding of literally everything within that system including your assets and so you can do these things properly um in a headless world you've got to figure that out to Tim's Point um or to your to your point I always speak to you as in the third person in these things to your point um it's like we're in a panel a panel of two uh you know to to your point um you know that's oh geez I lost my train of thought now um anyways it's a third person no sorry um how about I go into another thing that always grinds my gears and then maybe you can come back to what you had before sure so this is interesting right when you are affiliating a CMS or a headless thing or in the composable space have a look at what their oh I think we lost him okay well well Tim's internet is getting sorted out um I remember oh there you are okay yes if you were speaking please continue I'll do my rant after okay uh what I was going to say is um as as you mentioned we're headless cms's are starting to build some of those components and you mentioned that example of you know you've got your you've got your content item that's referencing other things in draft and they'll start to say things like oh do you want to publish those other items as well um they're also starting to do things like you know grouped uh publishing um you know where you can say oh I want to group these things and and schedule that so it's not quite as as powerful for example as um what psychor had which had that sort of timeline ability but it's certainly getting there to the point that it it will uh help you start to build and and preview things and sort of understand the context of everything in in that package of content for lack of a better word that you're sending along um let's see Richard um yeah um preview is often challenging because your content is not validated and requires defensive coding um yeah that's that's definitely uh one of the issues with preview and it was kind of related to what we were talking about earlier that you know you need to make sure that that context of everything else that you're linking to um is validated and and yeah you need to take that into account this was again one of the nice things that uh systems would have done for you in the past and you need to figure that out for yourself now again um if if that preview capability and the context of all those other assets is less important then that's something that you don't necessarily need to do right yeah exactly um I do want to come back to um stuff with code right when you do query these things in certain are in draft or whatever that is that's just that's one problem but then the next one is that I just started to speak about when my internet disconnected because I'm in the countryside um basically what that means is like how do the creators of this CMS think about apis and results and what is rest or is it graphql or is it some sort of strange mix which we see quite often because as you know rest is relatively strict normally you just get back one result and if that's five thousand lines and you need five it is what it is but more often than not you need more than what you can get back and so they have to start thinking about okay how do we then include extra fields or how do we include modifiers for filtering yeah lots of the times these things are literally just equations as strings yes which is really hard to test in your code there's almost like how do you unit test that well you can but you have to interpret that somehow and then on the CMS end of things they have to also write interpreters for that there's almost like query Builders and all string creators like I remember back in the PHP days when we created query builders for you know MySQL and stuff it's almost the same now on these API levels and then it just gets really hard and really opinionated really fast where you have a company like sanity investing in something like rock queries it's an amazing language to query in and it works very well but it's such a strange thing that you have to actually learn that so you now become a sanity specialist yeah that kind of sucks when you have to change or do another job you have all this extra knowledge right yeah well and that's a really interesting point about uh philosophy in in general of apis I think you know to your point there's there's more and more that you can be baking into an API you know things like uh pagination things like uh control over referenced fields and getting the content of those reference Fields into a single query um but to again to your point the flip side of that is that now becomes more and more proprietary to the query of that CMS and so the more you do that the more your front-end code becomes coupled to that CMS and it makes it hard if you're going to change systems all of those sort of specialty functions around our own pagination and references and things like that all of a sudden Break um yeah so lots more code to write and but on top of that imagine you are the CMS right you have written all these very proprietary amazing things that make developers love your system and you need to do an update or you need to change something how do you then deprecate a field or one of those operators it's be you're creating your own technical debt almost yeah and so um it's almost like it's very complicated because then if you do let's say something like a graphql API that's more dynamic then you're dealing with the performance downfalls of that thing and then also developers not liking it because it's graphql and needing a lot more um I don't know like the whole kitchen sinks you have to throw at it on your front and to be able to query that easily and so there's almost no good way and what I would love to do I'm not sure how we can do this but there needs to be a way that rest apis are this way I never ever want to see any more on error with the 200 header like why or anything in.net where you go to a 404 that first goes to 200 then redirects you with the 302 20404 all that kind of craziness is happening also on API level and so we need to kind of get it to be more structured and what I love about working at uniform where we just really use Json schema to really signify what things are and how they connect and that's how we all our data types and connections happen through this Json schema thing and that's a really interesting way it's also really hard to build luckily uniform has really good developers that can do these things let us just um I don't know how to say this and that's not Dutch and not rude anyways be Dutch Tim now I will not say this but it's it's really nice to work at a place that really takes that seriously especially because data comes from different places and we somehow need to serve that right and so the more composable you get and the more apis you have to deal with the harder it gets in your front-end code right and you need to somehow figure out to Super cleanly solve that and you can solve it code first by having like an API team where you proxy all these things and you you make cleaners and data mappers and all that stuff you see that quite often and bigger companies or you use something like a DXE where you don't have to do these queries and you just assign what data you need to each component but that's not for this stream but it's very interesting to see that all these apis are different and so make sure that you understand the opinions that your developers have to be able to choose that system and that's a pretty big part next to a Content editor that has to be happy if a developer is unhappy you will just not get as good as results yeah I can tell you that I am one of those it's yeah yeah I think that that is kind of in a nutshell the point of this whole discussion every API and and sort of system has different philosophies and different opinions and in a lot of ways they're all compromises right if you're leaning into One Direction you're going to sacrifice things in another Direction and so there's there's really not the sense of like oh this is the one way to do it um it it really is you know this is the way that we think works well for this use case and and you know again to your point Tim your developers are going to be the ones that are really understanding you know the use case and and what this thing needs to integrate with and what it needs to do and then you know therefore they'll be looking at the apis from that perspective right and also what's really interesting is when you start evaluating these these cms's just have to developer with you and ask questions because I've been in meetings where we had to have the CMS on where they did not expect us to assume that their content delivery API was for high volume so like we didn't build it for that it's like why not you're a CMS and so you always need to talk to these people to figure out how did they mean this thing because we don't have a standard right and so understand how these things work because the moment you are a huge high volume player you might want to just put everything in something like algolia that has an index that has a three millisecond really return of everything that you want that might be a lot easier like if you do it the right way algolia can be the fastest CMS in history yeah saying you should do that but you can and it's really interesting to see all the possibilities yeah no I think that's an excellent point and it's it's gonna I'm gonna sort of go on a little bit of attention and there we go well again I'm going to talk a little bit about uh platforms for Content operations and content marketing so something like gather content or um what used to be welcome software now the optimizely content marketing platform those are systems that are designed for Content creation and workflow and scheduling and things like that they're not designed to deliver content and so their their apis for delivery to your point we're never designed or intended to be high performance in the same sense of something like say contentful and so you know you can be using these things and it'll feel like a CMS and the apis will kind of look like a CMS it'll have rest apis for getting content out but it'll lack the performance it'll lack things like pagination and linking and all the stuff that makes uh content management system um you know really more aligned for the delivery and distribution of that content I think um you know on on the rant content management system is kind of a horrible way of describing what a lot of systems do because very true very true it's essentially everything is content management and nothing yes exactly so that's I think that's a whole other uh one hour discussion and I won't I won't get far into that but I did want to expand on your point too we can definitely think about something like a Pim system right where you yeah enrich your product data like I know Bim systems with like hundreds of API endpoints to enrich data to fetch data and to do stuff but async and I personally only know one that can do it in runtime which is Bluestone Bim which is a Mac Alliance partner these guys somehow figured out they have like 500 endpoints by default for all types of products enhancements enrichments querying matching things up it's ridiculously awesome and so it's not that normal for people in that space to have delivery apis they kind of have just management apis right yep yeah and again so you know you then need to figure out what you're using for delivery and and maybe uh you know we mentioned digital experience composition systems uniform is great for that sort of thing um in some cases you'll be doing things like static rendering and I think this is probably a good point to talk about the uh next point of the discussion yes um delivery Cloud hosting uh companies like netlify and versal Tim again these are my fresh opinions these are your favorite things let's let's talk about the thing is more favorites I for me it's like I just said there's like an explosion of Awesomeness when it comes to delivering your websites right now maybe not even websites but if all your apps or wherever stuff comes from and a few years ago we had the more old school dxbs plus the wordpresses of this world that would literally just have an SSR project so server rendered pages on runtime that they just bang a CDN in front and it's somehow one every 10 visits becomes an actual page that is server side rendered and rest is just in the CDN but then where there was this whole other thing that became even faster where it's all um like they call it Jam stack and what gem stack means let's not go into it because that's an hour-long conversation but at least it's very interesting to see how things things have changed now where you had statically rendered Pages where on the build it would make a static page and then just put it on the CDN and so you would effectively only have HTML CSS JavaScript media so it's not hackable or not really and it's super fast and all that stuff hey we have Diego let me just put that on here what's up dude nice to see you again anyways um so um of course for sales and Netflix of this world they jumped on that bandwagon and Natalie if I even coined the term jamstack and they were in that space and they changed the game because the main thing about how all that works is that they simplify the devops process by if I could say it personally a thousand percent like the moment I started using and it was back then it was more netlify and for salt didn't have that name even yet it's what's called site I think I figured out okay we have these serverless functions and now we can connect things up in the back end and then somehow in one code base without writing a line of extra devops related stuff have no CI and CD servers just have a git I push my my code and it literally just gets deployed and everything works I had this moment of like holy crap the internet just redefined itself and I had that about I don't know six seven years ago it's and you know it's it's funny uh just to interrupt I was talking to uh an analyst at the start of of jamstack and the start of headless CMS and you know like me they had been around for a long time back to the original decoupled cms's like interwarven team site that would do similar functions you'd have your CMS you'd render out static HTML and CSS and you'd push it to the server and it would be very unhappable FTP uh or team site had had this function called open deploy which would do things like diffs and you know make it easy and and they were asking me like well what's the difference between what's you know just coming out and what was 15 years ago not much right well architecturally and philosophically very similar but to your point the actual tools and performance and just usability of it from a developer perspective was insane like a 100x multiplier you know maybe a thousand like I just mentioned yes like I didn't like I'm old enough to have set up cicd servers with Jenkins and then you would do a build in a Docker container or not even before Docker I don't even know how they did it in the temp folder perhaps you would grab that output and then secure FTP to a server and then I hope it would work and then does the load balancer understand it has to go to five places like all these things I'm old enough to have done that and then when we switched to the more simple things it just changed the game so much and I love these companies that decided you know what it's the modern times are here we have enough cheap Hardware we can use in the cloud and off the cloud um to make developer experience um the most important part yeah and they have made it a revolution because now I can use a headless CMS that just sits there it's there it's just an API and then if I want to deploy something I just build something locally quickly and then just push it to that place by committing to git or literally dragging and dropping my files and it's done and that changed the game because now everybody who's Junior can use the magic yeah and oh Tim your audio is uh oh more I'm back and they often don't think inside of the Box because they haven't had a box to build yet and suddenly Innovation starts and um did you want to say something before I move into the next engine no I mean I was I was going to joke that you know to your point um even a generation ago CMS wise developers used to have require laptops that were basically servers in order yeah I remember that I I was one of those yeah and and now again to your point everything's done in the cloud you can basically be running uh very little performance wise on your laptops and now I joke that product managers need better laptops because they have to have you have to run the whole thing well PowerPoint and Excel docs and you know all these other things so it's the product managers that need the high Computing applications it goes even further now the companies like code sandbox that are pushing team development environments on the browser in the cloud with webassembly or I might say it wrong but something like that and it's so ridiculously fast and easy these guys are pushing the limit one more I can just go on my iPhone and code right so what was my tangent about I was ready to go in and oh I'm sorry oh we'll get there but it's like what I really enjoy is that they were able to that the the tech was far enough that they could use it and put developer Focus first and then these companies can grow and they make this amazing platform where they can just say hey but wouldn't it be cool if we also just could put a form on this website and just send it to our server done why not or wouldn't it be easy to have some analytics put it in for cell analytics best thing that happened recently and so of course there's a lot more we can discuss on that but maybe let's wait for that for a sec let's see what what else do we have here well I was going to say while we're talking about those those functions that are being built you know is is it worth talking about um static site rendering or some of the other techniques um that on its own I've been contemplating on making a YouTube video that's relatively long about all the ways you can render your front end and then there's so many and it's changing so fast that that video would be out of um being informative like in two weeks and so I think what's really important to talk about now is that there's just this pendulum that goes back and forth right so we started with these static sites we have to beat them up then it become all um like runtime rendering with the.net stuff and then the PHP stuff and then even with with node.js and then now the pendulum swung back and now it was all gem sex sites with extra fancy drizzled on top with JavaScript and now we're somewhere in between where you see companies like Astro that are amazing at rendering something statically and then render it but then they're adding SSR back into it and then of course like there's the The Usual Suspects like next.js that did this like amazing react server components thing where essentially each component can be almost like a little application that queries some stuff and then together it becomes a page and that is then cached then you can say how fast does this uncache after a certain amount of user or certain amount of time and that becomes a dynamic page but it somehow grabs different subjects from other things that you can use to make it awesome and I think next right before that was pioneering this whole thing and well next did the same it's a similar time frame where they had a statically statically rendered web page but then every subsequent page that you would load it became as an Spa so a single page app that only ran on JavaScript and then you had like this weird hybrid that was Best of Both Worlds and now you're going to see even more because next yes also came out with server components in View and so it's all over the place now and it's up to you to choose and if you are a for sale customer and you use nextgs you're in a really good spot just use their stuff do it the way they say because this is the one thing that me that I as a front and Def really enjoy now like I used to have to know everything about performance to be able to make a website perform follow the browser guidelines figure out the tricks of the trade to make sure that images are lace little lazy loading are fun to optimized or whatever streams in when and now that's almost just is the word ambiguous it's just normal now like I recently rebuilt my website in nextgs hosted on for sale because I just wanted to see the magic the only thing I did for performance optimization is say this image is lazy loading and this one is not and I had a hundred percent score on core web titles without doing anything and so it becomes very normal now so I would almost say is let go of your previous ideas of how I used to build it this is the way to go just kind of follow how these meta Frameworks come up with stuff combined with their cdns and their services and their apis and things like that and you will just build the best things and then you have more brain space to actually do the stuff you want to be working on yeah I think that's that's a really important point because you certainly on social media you often see this discussion like oh my God building web applications is so complex and there's all these dependencies and you need to know all these things and it is you're right but to your again to your point you now get a lot of that and you don't have to think about these things previously you know yes Webb was very simple it was HTML and CSS and and you know maybe a little bit of JavaScript on top and well that was not simple on its own because mental back then but okay yeah but you didn't have all these dependent Frameworks and uh you know includes and things like that and but you know I think I think that is the trade-off now is you know ddos's are the thing or a thing of the past you don't have to think about that load balancing you don't have to think about that you know you don't have to think about caching strategy in the same sense that you did before interesting you might have to because for sale has got it wrong recently a few times quite publicly where somebody's Bill became 15 grand after an hour right because some system had um a loop that that kept going recursively there's some stuff there but they're really good at replying to that and responding fast and helping you out yeah so as a developer who doesn't know about all the stuff you should mentioned you're quite a kind of good and then when you go to a scale like a friend of mine Josh works at a car company where they have like I don't know 700k sku's products and it's all in cms's and search indexes and scale suddenly becomes a thing then you need to know again but now you have great tools yeah right that's a big difference yeah yeah for sure uh let's see here maybe I mean we've we've talked about it a lot uh in the discussion you know how these things differ from from previous hosting models you know we're we're mentioning things like load balancing and some of those Dynamic systems uh is no longer in the basement yes exactly no it's it's funny I was I was thinking about that again you know back in the day when I was developing stuff on teamsite and I I did not have to think about these things yes I was managing the CMS yes I was managing um the build of these things but then once once I was using open deploy to get that stuff to the server that was an infrastructure team yeah yeah exactly so and and I think it might have actually been in our own basement for all I know uh oh yeah I've had like even until 2018 or 2019 when I was still at the agency we had these projects um where the customer said okay these are the servers you have but you know what we cloned everything because this one the first one after five hours the memory fills up so much it stops being able to serve stuff so then you reboot that one and you open up the next one yeah that would then fill up for five hours that's the failover and it just keeps and then you just script the swap uh that's hilarious being around this stuff but luckily now we that's a lot less yeah yeah for sure so yeah you should as the last subject talk a bit about what etch personalization actually means or whatever h means maybe do you want to take a crack at explaining Edge oh God no no well then I have to do it and I only have my personal experience and my viewpoint as a developer to talk about but maybe we can just keep it simple as simple as possible and then if there's anyone in the audience who wants to mention something about what I say wrong feel free um so essentially what what we like about a CDN Edge The Edge is like on the I don't know how you could explain it but it's like on the outskirts of the CDN as close to the user as possible that's the main thing if something is on a CDN Edge you can expect it to be very close I'm in the countryside in France so I'm assuming the next big city is to lose that's probably where my CDN Edge lives so if I now go to and I need a specific piece of content or data it comes from there so it's decentralized distributed on the edge and lately The Edge has become more powerful there's been a lot more things going on but because essentially what they wanted to do before is the ad had to be the fastest ever right it had to be like 10 milliseconds you get your stuff so what that means is that these servers that we're running Edge were slow well they weren't slow but they were simplified so they would be fast so you couldn't run certain operations on them because it would take too long it would just serve content yeah static content without too many headers attached simple stuff no compute and then you had serverless functions that would be close to the edge but not really they would do all the compute stuff and however maybe about a year ago we started to realize what if we could do more on this Edge wouldn't that be amazing because then I could run on an edge in France something for me that's specific to me and then you would have an edge in Canada close to where you are that would do something specific to you and that becomes very interesting and so they had to figure out how can we make these Edge networks these servers they sit there right how can we make them fast enough and simple enough to still be fast but give you compute or give you like if else capabilities or something fancy right that you can push to them and this is when they started especially Netflix I did that really well and now for sale came up as well and I think cloudflare is good like um Azure is coming out soon with it a lot of companies have this now because these ad networks existed they just had to make them smarter and so they started to run very lightweight node.js or python surfaces on there that didn't have all the features like you could not actually have a file storage you cannot touch a file or you couldn't do certain operations because it just takes too much time and so they have like maybe it's no longer node.js but it's bun or it's Dino because it's a much lighter executable and this is a very long way to get to the point where we are right now where you can do a whole bunch of things on that edge and especially the the most famous ones are cloudflare's epic and they are the most liberal with what you can do on the edge it's the easiest to use well maybe I shouldn't say these things anymore because in the end it's all easy to use and then for cell and natalify have come up and there's a few others Akamai also even does it but it's their old style so it's a challenging but it works and what you can do now is every request you send as a user that uses a website to whatever that website is running on has a function that pushes it through an edge Handler and we can we and they sometimes when you're in like next JS they call this a middleware file so essentially whatever URL you go to it goes through the edge first and then it renders your page and so if you don't do anything on the edges it's really fast because it's just it returns nothing but what's very interesting is you have a bit of information in that function which is the location of this user what is there I don't know maybe their device information or maybe whatever and so what comes in is a it's actually streamed so the HTML that you might want to serve to that user is also available in that edge function so what you can do if you do that smartly and super in a fast way you can actually say okay I'm getting all the HTML now for that request and maybe I want to change that a little bit and Stream in the fact that I'm in France or the fact that I'm in Canada and then do something else on that page and then return that as a package of what the actual HTML is so you have Dynamic rendering on that edge with the information of the user at that edge point and then suddenly things get magical right you can do exercise personalization that is hyper fast because you just stream in Little Bits but you can also do other things where something like next JS the qgs framework that looks like next but is in my opinion super fun it's my favorite it can run fully on the edge you can literally have a dynamic next app running on an edge server which is ridiculous there's literally no origin anymore because it's so small it and it fits so well with these runtimes like Dino or bun or whatever they run um that you can do hyperdynamic things like that and I can talk for a few more hours on how fun that is but maybe that's not for today but well the game changed again let's say yeah so I I think it's worth talking about then how how do we at uniform use Edge functions to enable personalization because I think that's you know to your point those Cloud networks and cdns and Edge is is enabling that use case but you've got to do some work to get that to happen so in uniform not so much which is what makes it so lovely like the uniform SDK is relatively light you add it to your web page or your project and it can it connects to uniform obviously so it gets all the data including personalization information and so maybe I can talk about uniforms personalization for the client side initially so if you did it with JavaScript no CN Edge is involved and then how that is moved to the edge yeah and please um correct me if I'm wrong my uniform colleagues if you're in the chat I'm just going to give the high level overview because we're not going to give away too much of the IP also right there's that's not what we're here for there's still a bunch of magic that's ours but anyways initially when the way uniform works with personalization is that there's not that many rules we don't really like rules because you have to be a PhD in rule making if you have 15 components you want to personalize based on certain users right it's really hard to if this done that and put all that in so what uniform does is there's a Tracker on the web page that knows what people do what URL did they press where did they scroll to did they go to a specific place and then liked something or put something in the basket and there's all these you can almost if you're a developer you might understand this if you're integrating with an Analytics tool like Google analytics you add events for all actions people do right so that's also kind of how uniform tracks people and you can choose to store that this information in a cookie or in the session or in um like local database or just in memory so when people refresh the page the personalization is gone and every time people give signals uniform figures out okay so there's a signal that somebody liked a certain thing so when I now go back to the home page in my content editing in uniform I can say if this signal is fired or it has a certain score let me just render another component so in the uniform interface you can just say okay I have set up a few signals that I think are in important maybe somebody likes a specific product category so they go there four times well that's a specific signal that you send right so it scores a little bit of points so essentially you can have for multiple different signals and actions that people do you have different points scales and based on that different components are rendered in the page so you can do a hyper personalized page based on the actions of the user okay so that's how we do it in the front end with JavaScript so you can literally just click around and your page totally changes based on your actions that you made without having made too many rules of course you need to know if somebody likes this I'm going to render that that's pretty normal in personalization so when you have that in place the problem is when you load the page the first time and you have to figure out with JavaScript what all the points are that people had from last week you see a screen flicker a little bit so we change the components suddenly and that's not great it worked for subsequent page clicks because when you keep clicking it something becomes a single page app and it's super fast but what if on the server side of things you can already have something pre-personalized send it to the to the user and the JavaScript attaches later suddenly it is already personalized so you don't see screen flickering no flashing none of it and that's what we do rather than in An Origin server in the back end this is what lots of Legacy personalization would do where you would take five seconds to figure out what all the rules are let me render something and send it back that is not something that works and but if you do it on the edge and it's fast enough if the way you wrote your code you can really do that and so what uniform does is it looks at the cookies in the session of the user gets that information in that little middleware function I was just talking about when you go to to a page there's an ad Handler you get all the information about the user and you figure out hey there's this course we just collected these last week and then on the server we just swap certain components based on whatever uniform has in their personalization tool on the side stream them in and then return the page and that's the simplest I'm going to give it to you you can go to the uniform documentation to see a few graphs of how that how that would work it's all on there and the interesting bit is that we can do maybe 15 cms's and a few different systems all on one page then personalize everything in a visual way and then still have a 50 millisecond batch load yeah I think that insane this does not exist that's why it took me so long to explain it and I I think that's kind of one of the things that uh most people don't really uh think about when they think about personalization is especially how it's done with older systems it's it's very slow because there is a lot of computation that needs to happen behind that and and one of the problems with with personalization is typically you're dealing with um small amounts of uplift right like okay we're going to personalize this thing and we're going to get uh five percent uplift and over you know a million dollars yeah that's fifty thousand dollars it's exactly it's not bad it's not bad um but the the flip side of that is if your time to deliver that page falls dramatically you will actually lose users and lose revenue and lose even more yeah exactly yes exactly and so this is one of the problems with personalization that most people don't consider is that when you're doing it it's it's kind of like uh you know Heisenberg's uncertainty principle that once you start to do personalization if your uh performance gets into that zone of of affecting the revenue the you'll actually have a net loss and so I guess you'll be personalizing but you're going to be losing a lot of people in the process what's interesting here is you can do it like look at Amazon they have perfected this and it's still fast and it still works but not everybody is Amazon right that's the thing not everybody is Netflix that does a personalization thing or Shopify or Spotify with uniform for the price that you pay everybody can do this and content that others can officially say this component comes here this one comes here based on whatever thing was just said and it's a different move into that field and using the edge for it is it feels like for us having been in this space doing this personalization bit for a while it felt like the most organic move to do it that way but then when we were discussing this with the net levising for cells and cloudflares of this world they looked at how we used their Edge and they're like we had never anticipated anybody ever wanted to do it this way this is awesome and for us it was so normal due to the nature of how uniform works and that's why sometimes it's a little bit hard to explain it took me like a good five minutes but once you see it in play it's crazy because we then also integrate with a whole bunch of systems like crms and cdps and something like sixth sense that looks at IP ranges and emails of people you can go to the uniform website when you are let's say you work at algolia or you work at content stack or one of our partners the home page will be catered to you and you would not know it any different because it's it's like a normal website it's that fast you don't even realize it was personalized for you and if you do that the right way and you put that on e-commerce or on events websites it's unbeatable like how often have you bought a ticket for something for a conference and you go back to the website and ask you to buy a ticket again actually that's stupid it should tell you you already bought this ticket or you have something in your bag and you clicked on this link five times maybe you want to buy it those kind of sis like these three things that I just gave you if you want to do that with traditional personalization tools you see product owners developers everybody start to cry because it's just maybe in version six of this site right and for uniform it's just there you literally did that with four clicks and so it's a game changer and it's using the edge and it's super modern and hip and I really enjoy that part well and I think I'll take this opportunity to tie it back to something that we were talking about earlier yeah we should because we went away from cdns and API yeah no no I mean this was part of the agenda to discuss but it's you know as we're discussing that and we're talking about underlying content systems that may not have good performance uniform can also improve the performance of consuming content from those systems as well because everything that we you're talking about for those systems and pipelines for personalization also just applies to content in general right actually we should say this because we are using the edge for something else as well as uniform so what we what we have now is I'll keep it short because we're flying through the time here basically in uniform you can add data sources to uniform so you make your composition you have your design components and then these external data sources you can literally say this title field needs to come from that source that field and then this image needs to come from that Pim that field and this other text or this list of items need to come from this specific CD API endpoint right so you're pointing to things but then what uniform does is rather than storing the output of that whole API endpoint what a lot of systems do we don't we still point to it and so what we save is something very light if we just have pointers to data resources in fields and then when you actually hit the uniform endpoint from your front end then you hit a CDN Edge close to you and on that edge we have actually figured out from that data resource ID for that field what that field is and we put that in the Json for you so we store a very curated a list of jsons specific to your components and their properties and that sits on the edge so we have like I don't know if you're in San Francisco you have like a six millisecond real response to something that might have 15 data sources because we almost like it's like a curated form of things that we need we put it together and when we cache it for you and then of course the developers in the Stream might say hey but then are you just cloning the cash or how does that work and so we can actually have per Field Time To Live and web hooks so when you publish something in your CMS the web could go to uniform and we would just uncache that little three fields that you used and so that is insane again doesn't exist right so dxc is next level with uniform and that's this kind of the thing we're doing and it's um The Edge is basically me like it's right place right time tools like the ads that exist now make us so successful in doing these things before it would have been a lot harder well and I think I know we've just got a minute but I think to sum up that's that's probably one of the biggest takeaways is that the world used to be very binary you know server-side client-side and and now it's much more of a spectrum to say okay server side client-side things like digital experience composition and uniform things like Edge compute you know there's there's a lot of different functions and a lot more sort of uh Variety in in what's being served when and where um and you know it it adds complexity for people to understand and certainly that's why we're doing things like producing this guide and having these videos but yeah you know hopefully people can understand the potential of the things that Tim was talking about in terms of okay now it means that the performance becomes much easier it becomes much easier to manage and understand and and you know actually deliver those things exactly it's a magical time to work in the content space I think yeah yeah I think at that that's a great great summary that might be the ending bombshell so feel free everyone to look at this URL or scan this QR codes to find our affiliation guide of composable CMS is where we basically what we speak about here is a wider ranging thing but all the Core Concepts are written in this guide so you can learn a lot from that or fully disagree and then talk to us we love that too yeah and and to to Tim's Point um you know the guide has a lot of the stuff at a high level but you know really for the details we're we're getting into these live streams if we were to have all of that level of detail in the guide it would be a book you would not want to read it so you know take take the guide pick and choose those things that you need to understand conceptually for those use cases and then for the specific topics uh come see us as we discuss uh these things on our live stream going forward all right um I think we are at the hour exactly or a bit over just anyways um thanks everybody for watching and um we'll see you next Tuesday right yes on headless Creator same time on headless Creator cheers everyone foreign