---
title: "Composable CMS evaluation: SDK frameworks"
description: "In this episode, we discuss SDKs and how to interact with CMSs. Choose wisely!"
date: "2023-07-29T01:52:04.000Z"
url: "https://timbenniks.dev/videos/live-uniform/032-isxyi-5do5o"
youtube_url: "https://www.youtube.com/watch?v=IsXYI-5Do5o"
playlist: "live-uniform"
duration: "48:22"
image: "https://img.youtube.com/vi/IsXYI-5Do5o/hqdefault.jpg"
tags: ["composable-architecture", "cms", "api-design", "frontend", "developer-experience"]
---

# Composable CMS evaluation: SDK frameworks

In this episode, we discuss SDKs and how to interact with CMSs. Choose wisely!

Watch on YouTube: https://www.youtube.com/watch?v=IsXYI-5Do5o

## Transcript

are we we are live we are live every time we go live we're like click oh no there's another click and then anyways there's that there's that little lag it's uh aside from that stream yard's amazing absolutely amazing yeah it's one of the better tools anyways um without all that um welcome everybody to our I don't know fourth or fifth stream already yeah um about um CMS evaluation and how to buy it and all that stuff you can actually find the content that we created here on the uniform website so I'm here with Mark Mark talk to us about yourself for the people that are new hello I'm Mark demini and I do a bunch of stuff for uniform but right now I'm doing the live stream with Tim that is one of the better introductions I've ever heard this is proper Friday morning for you right it is yes exactly all right so today let's let's open our agenda so in the context of you know choosing a composable tool or CMS and how to evaluate what you have to buy there's a few things you have to consider and today we're talking about sdks and specifically um it's like the software development kits for the front end and so first of all we'll talk a little bit about what sdks are but then also all the things that we think these sdks need and then it's up to you when you evaluate whatever CMS you're going to buy if you need these things right and then there's a few things that we would love them to have but that's not always true um and then of course we work at uniform so we want to also discuss like how does the uniform SDK work and how can you use uniform as a proxy to watch these cmss from your front end and so yeah there's lots there I'm so Mark what is an SDK an SDK stands for a software development kit um and beyond that you know to your point there's things that we would expect in SDK to have but beyond you know there's no real official definition of what's in an SDK exactly you know so I think that is what it stands for but really the idea is that it is a bunch of code and potentially documentation and potentially examples that are written for a specific language or framework that interact with some underlying system and the reason software vendors do this is to make it easier for you as a developer to connect with that system and um you know in some cases there's things like helper functions in some cases there's um things that do a lot of sort of boilerplate code uh for for connecting to just make things easier for you um and in some cases it actually goes very far into into you know real full built out examples for a lot of common use cases and so there's a lot of variation there um but in general that's really the purpose of an SDK um I think that makes a lot of sense and in the end you probably don't need an SDK if you can just talk to an API if you need an SDK for a CMS there's something special there so it means that something might be hard to render or there's something special going on which doesn't mean it's a bad thing but generally if something has an API and you're one of those people that love to go deep with code you probably don't need that SDK right there are some examples like for example when you take algolia and their instant search you probably want to use their SDK because it gives so much richness to your faceted search interface why build that yourself if it exists right but then for other things like you know querying a contentful or a graphql type of thing you just query get the data and do whatever you want anyway so um let's see in our agenda what the next point is because there are if we look at Point number two there there are different ways nowadays that we render that we can render front ends and maybe we can just talk a little bit about how to how you can render front-ends to different approaches and then if that actually matters for sdks or not so what do you think Mark does it matter uh I think it matters a little bit um you know you look at examples from from vendors I think it matters a lot for getting started quickly and and understanding it I think you know when you were saying earlier um if there's a good API you don't necessarily need an SDK uh somebody like me who's developer-ish former developer business user whatever you want to call it I think I depend a lot more on those things to get started so yeah you know for example I'd go to contentful and say right uh I want to try contentful uh you know with this programming language and chances are it would have that SDK already enabled and already have some example code and so I think for somebody like me that helps a lot um and that helps a lot in the evaluation process in particular true very true you know to your point though once you're actually getting in production you you may rely on that SDK less right because you may say do we really need it it's one more dependency you know what types of queries are we actually doing and and so you may kind of use it as a little rocket booster and discard it later on potentially right and what actually I just that came to mind what is interesting here in the different ways that you can render website sites so let's go over these and I'll then I'll talk about certain SDK features that you might want to think about differently based on different ways of rendering and let's keep this as simple as it possible because we can talk for five hours about how you can render websites nowadays I think the simplest way we can say is you can render a website or a page at runtime so the user hits the browser to the URL goes to the server it comes back with whatever that URL signifies so that's surface unrendered and then on the other Spectrum the other side of the spectrum you have a single page application which is fully JavaScript so when that URL hits it actually goes only into the browser and the JavaScript renders your whole front end and then inside there after that JavaScript is loaded it starts to query apis and whatever and then data comes back and it populates and both of them work fine you just have different approaches for them and then you have many things that are in between right um the the one that we used a lot up until recently is you might actually not do SSR but you you might statically render on build all your pages so when somebody hits a URL a static HTML is literally shown and then it gets enriched or hydrated with JavaScript and then it becomes a single page app after the first subsequent click that you do in that website because spas or single page apps are great for not having to reload the full browser you click on something and only one or two bits change that feels a lot faster you can do animations you can do a whole bunch of fun stuff with that so the one in between is basically a jam stack site yes that word still exists and then subsequent clicks hydrate whatever that page is and then things start to happen more smoothly as of reasons there are other approaches too now where you have react server components and you also have next server components now where essentially everything is server-side rendered again but with node.js or react or whatever whatever they choose for that and there might not be a JavaScript variation on the client side for that component it there and but you can do that and companies like Astro pioneered that where you could have a pre-built site and then sometimes it's only back-end components sometimes it's also front-end component you can call this Island's architecture and then when next and react came in is where it's a real server size component that just get cached on the server and you can say cache this for five minutes or 10 seconds so it is a service that rendered on the runtime page so highly Dynamic but then gets cached and it's hyper fast and so it feels like a static page again and then you can choose this one is is client-side and this one is not this one looks with an animation and so as you can see and it's huge and there are many approaches that we shouldn't talk about now because we just confuse ourselves and others but with this in mind there's something very important to consider what is sdks because generally this front-end sdks are built in JavaScript typescript node.js stuff like that and they come with a lot of information in the Javascript file that you need to be able to run them and if you have something like a gem sex site right where you have a static site that's rendered and you're using that SDK to query a page and grab some rich text and convert it into something all that stuff and you need the SDK for but because these are JavaScript packages they also go into the bundle that is then sent to the user on the front end because when you are in that single page app and you click on something it has then also has to be converted into that next page with a payload that it needs so it needs that SDK again but what that means is if that SDK is huge for every time you go to a page the first time you have to actually download parts put in memory and cache that whole SDK and maybe that SDK was meant to only be used on the server side and if you only did a server-side rendering it would never end up on the client side on the user so potentially the way you render your site you have to be pretty smart about where do I put my SDK and how much is going to the end user of that whole toolkit that I might only use to render one page or query one thing yeah I think the the point of this is uh thank you for pushing me to watch The Point thanks I was gonna say I think the point of it is one it's it's fairly complicated and it's sort of it's you know understanding how important an SDK is is also related to understanding which of those approaches you choose you know client-side server side somewhere in between and whether the SDK is is suited for something like that as well um and then for example where I used I think back in the day it was prismic CMS that I used and it's not here to say personal SDK is not it's actually one of the best out there but I didn't realize what next was doing with my website how much was pushed to the front end and how much was staying in SSR where I was rendering these pages to be static right and I didn't realize it but I was pushing a lot of logic even unit tests a bunch of stuff to my front-end client I'm making the JavaScript files heavy you know what when you think about having a fast connection and fast devices it's not that bad to have but when you then go to a website where they don't do it it's so fast you you it's crazy and what we also should realize is that I think 80 of the world does not have the internet like you and I have it here and so loading just a react application in in Italy on the countryside takes you 20 seconds yeah I think that's the whole SDK in there is there's no need yeah and I think um one of the things that Google has done very well with Lighthouse scores is is really reflecting that reality they're basically saying hey when you're looking at the performance of a page we're assuming that it's going to be an older device running on a you know mediocre internet connection and and that's intense that's really why they're doing that is exactly you know to your point yes you might have a really good internet connection you know wired up in your house um but uh you know certainly in the Canadian Countryside and probably the same for the French Countryside in you know mobile internet is not that great um so I'm running on that now though so pray for me I think it's good I can see the the antenna Bowl right there outside oh that's not too bad we're okay now with like even when when I gave that example of just now I removed the rich Tech rendering SDK because I don't I don't need it in the client side I only needed to render my static pages and I removed a few other things and I I think I removed 50 of my front-end client bundle making my website that much faster yeah no that's take this into consideration how much of that SDK do you push to your users yeah um I think that's that's a good lead-in to talking about you know what an SDK typically or often contains so you know you'd mentioned stripping out a few uh elements that that SDK provided um there's there's a lot of other things that you talked about you know preview sdks uh how you handle Rich Text um why don't we go through a few of the examples of yeah what a CMS SDK often contains um and then similarly at the end of that you know when we talk about things like docs examples and starters I I'm actually going to bring up a browser and look at a particular vendor example and kind of talk through how they do it how they do it yeah exactly so I wrote down a list just now of what I think has to be in there or not has to be but it and you know what certain CMS is you just don't need it because they don't offer certain features but yeah um for example certain CMS has come with a very rich media management and delivery API well if you use an SDK for that right and then others like prismic has a prismic image tag in all languages that has an amazing piece of SDK kit behind it but then when you go to others they don't have that at all because you handle your images yourself right so there's different choices you can make and so let me just read out my list here I'm going to put that in um in the chat here for others if they want to see that just put it in here so essentially we have a query Builder to just say give me all content types of type blog and order it like this and then follow the first Connection in it something like that yeah well and and maybe even do things like pagination exactly all that could even allow you to do some filtering some you know sometimes that's on the SDK level and yeah a bit of search stuff like that exactly so that one is the core every SDK has we'll have this um and then there's another one that is very interesting we see more of that recently where you need somehow people in headless CMS want to preview their work and so there sometimes are different types of sdks different packages inside a bigger SDK perhaps that allow you to do preview and so we have different approaches to this like um if you look at the likes of storyblock that's fully preview really awesome they actually have a few DS or a react component that you put on the page and that will help you render the components but because they own that component they can actually attach their preview to that and you can do drag and drop and all that stuff and so that's a separated bit that comes kind of out of the box with them but then when you go to content.ai for example they have a much more agnostic approach you just add an ID or a certain attribute on HTML the CMS in preview mode understands these attributes and then renders some preview stuff for you which is another very good approach and then you have sitecore that has something in between right and so preview sdks are things if you have preview you likely will have some form of preview SDK because you kind of just want to when something changes you might want to send a post message or a web hook or something to refresh the page that you're looking at and it also has to know you're in draft mode not in published mode so all that stuff comes with a preview API well then we have another big one rich text SDK because every CMS will have a rich text and for a long long time you would just get HTML back from these things and that HTML that you good back would have a lovely Json structure and then a big chunk string of HTML and that would never work with whatever you had going on CSS it was math well it and also even um like mobile applications really just couldn't work with it well at all so it's a one channel kind of thing right and so nowadays what these systems do is they have a little language they created for this is a paragraph and this word is bold and there's a link here and then it's a whole Json structure it's like a like a graph of whatever that rich deck was when you were editing it and it's just a Json language and so you could parse that language yourself and build HTML or you just use their SDK because it's exactly built for that and so that's another piece of kit that you really want because the lovely bit for good CMS is in here like contentful has a really good one pressmick has a great one um I know kccms has a really good one um I haven't seen many others here but they would actually say if I hit a P tag or an image write me a little piece of code that can hook into it and then you can write your own image tag with your own lazy loading and your own fun thing yeah and that actually then it becomes very interesting and important because an SDK should not say an image always has a p dag around it that's a silly thing to do well contentful does it I hope by the way sorry to say it like that they used to do it I cannot say if they do it now but they used to and stuff like that just makes no sense like you have a UL with a list and they put a paragraph around it yeah I think it's probably worth saying Rich Text handling is probably one of the things that people don't think about a lot but it's it's potentially one of the biggest sources of problems it's like it's like an iceberg right yeah it's it's the hardest things in CMS and web development in my personal experience is images and Rich text the two most basic things ever are the hardest to deal with well and I think the third hardest is the next one on your list which is uh link building link building yes that's yet another one and so in my personal experience um sometimes what you'll see you might in a CMS link to another content type right and you might and either you say hey this is a link with a little button that just goes somewhere or it might be a connection to another thing and you might want to render a link for that in your front end like a button to click your Atlas CMS will never know the way you can link to something else because your url it should be agnostic right you can have a web interface then we can have an iOS interface we have a refrigerator those have different ways of linking so if you have a bit of SDK kit to help you to create the link for the channel you're dealing with that is really important and I don't see this coming back too often so Mark do you know any sdks that give you this other than the one I know which is prismic uh I don't I don't think so because to your point to CMS generally doesn't understand the full context of of where that item is being used yeah exactly so you know I think there's there's some that kind of combine a little bit of Rich text and and Link building potentially so like you know contentful allows you to insert sort of content from one item into the rich text of another yeah I've seen that that's actually pretty cool yeah which is pretty cool yeah uh not every CMS uh enables that um but uh but yeah I mean it is I I think it will become more and more important uh well it really depends because it's it's one of those like lovely ease of use things that that content editors just want they want to be able to just select something in a rich text field and make it the link to another thing and somehow the developer just needs to deal with that even though maybe you see a mess shouldn't be doing that at all but that's for another time right we need to kind of figure out where that sits and how idealistic do you want to be look back at our previous session where we ex where we talked about this in depth and so and then the last one that I have on my list here that I wanted to talk about is like external sources and how they integrate because certain cms's would let's say do an integration to a Commerce system and then when you query that it only gives you back the IDS of these items but sometimes it actually caches a bit more data on its own CMS or it's just just different way of pointing at data and sometimes you have sdks to help you and sometimes you don't and so this one is relatively light I'd rather have an SDK that doesn't think about this so I can just use the SDK of that Commerce system to query these apis items um that sucks let's be fair I don't want to have five sdks in one front end to be able to preview in my my Commerce preview my front end link to this like that is not something you want you want don't want to glue shut your whole code base so that's a that's a little um hint we're going to talk about uniform soon yeah well and and before we talk about that though I think it is worth noting that there are some cms's that really specialize on that Commerce that description use case yeah um and I think it's it's worth considering that like yes if your Commerce you know if you are specifically doing stuff around Commerce and integrating there uh you know systems like amplants make sense they do a lot of upgrades to have crazy good what they do like for example search is always a Hot Topic in cms's they're not great at it because they're not built for it yeah and then employees just decided you know what we'll just give you the best search Ever by integrating algolia done yeah right so they they have this whole shopping approach they call it shopping I think nowadays rather than Commerce and they do that extremely well so it's also the choice of you know what does your CMS want to do yeah I was going to say I think in in some cases we're sort of hinting at the quality of the SDK and where sdks [Music] Focus what they do is often very closely related to the functionality of the underlying CMS I think you know this is this is one of those things if you're a vendor that's building some specific function into the CMS part of that completeness is building that function into the SDK for people to take advantage of it it doesn't make a lot of sense to develop something really deep around image handling or Commerce handling and unless you also have the SDK enabling that use of that function exactly totally true and so I think some other things that I didn't really talk about yet that sdks need is documentation yeah say that again documentation that's up to date sorry I had to do it why don't I pull up uh uh a couple examples here where is it I got too many browser tabs oh yes this is the the luxury problem of Modern Age here we go is it this one yes okay let's let's put that on the screen here yeah so you know we're we're talking about while we're talking about documentation I would also lump in example codes and starter kits and yeah 100 of course that's part of that that game yes yeah so we'll look at uh contentful and content stack um I think that's a great one yeah contentful is a good example you know you can see here they've got full technology guides this is what you should expect from a lot of vendors which is a number of different uh languages including JavaScript Frameworks including stuff that's potentially server side you know in a lot of cases you may be integrating into an older Enterprise application so or if you are it's worth noting okay maybe I still have some Java stuff kicking around or net stuff kicking around um you know let's make sure the apis include that um you know what else here so I'm going to look at a next.js example and yes interestingly is there's not a next SDK there's a JavaScript SDK which typescript that and then this is an example in xjs so don't expect people to build you a next or next SDK the SDK is just as Gnostic and this is an example using it yeah um and so in this case this is a really nice example um has some command line uh is that command line tooling no it's just no this is just command line functions yes yeah um you know create your contentful account hook that up so this is not an SDK this is just an example of how you can use it which is very important in documentation yeah exactly I think where was maybe it was a different example that I looked at that actually did have uh maybe it was in react that did have some functions so ah in this case here there's there's some starter code um that they have for that react starter so this is again that's not the SDK though that's just how to use the SDK with react yes exactly um so it but all of these things kind of go together which is yes very important yeah and I think it's so important to do it this way because when you look at a system like next like a framework like that they have this module approach and so you can actually use like this here you have react you can just use the the SDK from content for with react and just bundle it somehow and do it and you can do the same with few but when you go to to noxia she has this whole module approach and so what you start to see is also uniform does this specifically for next DS they make a module to connect to contentful and that makes it even easier so that's an SDK wrapped in an SDK so that does exist I'm sorry to say but yes yeah so so yeah I I like contentful's examples a lot exactly um you know good good to work through uh another vendor worth looking at is is content stack uh now so many that's right they have a lot as well uh one thing I did want to highlight you know we're talking about sdks um there there is this cons and but today we're specifically focused on content delivery sdks uh we will have another session on content management sdks and developer tooling and things like that um so I just want to point that out though that when you're looking um you know these you have different sdks for different purposes and then things like utilities so this may include things like import exports um you know other other functions that little icon at util's sdks in the end is that Dart that still exists wow and did they repurpose Dart for something else nowadays I think so I don't know I was I was working at agency when Dart came out and we built like a really cool thing with dart learning like all the like it's basically typescript like but then by Google and it was ridiculously awesome but also so one-off that we never did another project in it yeah I was curious about dark the dirt 2.0 essentially yeah but then Microsoft typescript just won because it fits so nicely in the JavaScript ecosystem anyways this is a not at all for this stream but I was really surprised to see a dart SDK yeah um so yes I I just want to look at show content stack just to show you know the the difference between content delivery content management and other utilities and we'll talk about content management and other Utilities in another session um so yeah those those were my two examples there uh sorry to say I know Dart is now used for building really cool um mobile applications sorry to interrupt I just no no that's okay um things like that yeah anyways um so we covered the docs examples and starters but also the multi-programming languages there's there's lots of cms's that don't have sdks in Java and PHP and all that and then some like we just looked at the more Enterprise focused ones they have it for everything which I think is really good because Enterprise projects have the strangest things you have to deal with and so you have to be as flexible as possible or you just lose so that yeah and I I think it's also worth noting uh you know to your point some vendors only focus on you know one or two languages they might just have JavaScript examples and not have um dot net examples or Java examples it doesn't mean that you can't use it with those systems you just use an API you queries yeah you go you just make your own SDK essentially yeah you just have to make your own SDK so you know in the end I think sdks are important and helpful but they should not be deal breakers is that fair to say completely because you know what um I've had a lot of successful projects done without using the SDK because I just needed what I needed and like even when when we were working um at uniform and we were building our SDK our first one was was react only worked extremely well but I'm a few developer mainly and I felt like hey I want the same convenience in view so I just built my own and that in the end we gave that to our product team made it 10 times better and now that's our SDK so you can make your own thing that just fits your use case and then it you might productize it or not like and the thing is this is the one big difference here you can make your own SDK because you like a certain way of coding right the only problem is you will not get support from the CMS on your own build so if you are in a space where slas mean a thing where support um Professional Services means something to you never build your own SDK let them offer you an SDK or you're in for pain it's simple as that because when they decide to choose an endpoint change and they don't use like a lovely Json schema deprecated field kind of thing but they literally just change a field name your website breaks and you're done and there's nothing you can do if you have an SDK by a company they give you or they should be able to say hey we changed the field so the SDK is updated npm update you're good to go yep now that's a excellent point yeah so we should have put that on the agenda but it just came to me anyways yeah um no let's see so I think I think that's pretty much everything from uh front-end development perspective and sdks uh let's talk about uniform and their sdks yeah so this is a slightly different ball game to because we are not a CMS and so we kind of get data from different places and then put it on a page and then you have to render something and so uh the uniform SDK looks quite a lot like I don't know we chose certain bits and pieces from other sdks that made sense like the most important thing with uniform is it's also user generated because it's you you have data types on to and connections to a lot of other systems you grab these connections and you put them on components in your preview right and so that means essentially the paid that you create is curated based on whatever data you get you put it in a certain order the components look a certain way you hit save that means everything is user generated so this is not like give me all the blog post types no that's not what we do right it's a different style you can do that with Dynamic pages in uniform but it's not really meant for that and so how uniform does it is you get a whole list of components and the names of these components they fit also your front-end components right it's your design system so it says hero variation image left with that image with that title with that subtitle and that rich text and the next component is Introduction with just this text next component is a list of blog posts next component list of products whatever and what comes back is a list like that header with three Fields introduction then list with five Fields stuff like that and so what our SDK has to do is actually first query the composition of course based on the URL slug or something whatever an ID you have and what comes back is a list with the order of which components has which data and looks in which way and so uniform literally just says okay this hero that I get back from the Json I can match that to the hero component in react that we just loaded okay let's render that and so the SDK of uniform actually puts the code includes it and puts it on the page and then hydrates it with JavaScript or whatever happens and it of course it uses the next or next or whatever SDK endpoints you use it understands these Frameworks so it adds the data and so it's literally a dynamic Builder and putting components together system well that was a long sentence that's a very different SDK it looks much more like how storyblock would do it right where you have a visual editor where you put things on the page that are just components and then you just render them like if you wanted to do something like this with for example I think this content stack they have modular blocks right yep well they don't have an SDK to render these components for you there you just get this is the order of the components so what you now need to do in writing your own code is actually say when I hit this component I know it's that piece of code so let's include it and put it in the JavaScript or however you render your web page so uniform has a pretty light SDK that just queries that composition puts the stuff in place but because we do it that way there's lots of bits and pieces that you can suddenly start doing because when you want to do personalization did you have you might have two variations of a component well that comes back into Json and our SDK has a sub SDK that you don't have to know about that understands personalization so it looks at the actions the user did maybe there's some cookies that were saved or some session tokens whatever and then it chooses the right component for you you don't have to code that yourself and so uniform has a light SDK that looks at whatever extra packages you have like personalization Dynamic Pages things like redirects a bunch of stuff like that um what else do we have there we have like um your project map which component goes where based on what URL things like that and so if you don't have these installed the SDK is lighter but you can install them so they're all set sub packages and then in that one bigger function that you use the magic happens and even then it's really light and because we control that whole flow of your components preview is baked in because it's super simple that way and so you see how that SDK is actually quite different than most CMS sdks because it's just not a CMS it's a designer Builder thing okay that was a very long way of explaining it did that make any sense for you mark uh I I think it did I think it's it does make more sense if you know what uniform does and I think you you did a decent job sort of explaining up front that it's less about fetching an agnostic item and more about fetching the structure of of what you've built in uniform and then in turn getting the items to fill into that structure right exactly that's exactly what it is and so um and so what essentially uniform does and this is where it gets slightly more complex but also way more awesome is essentially uniform is a design system you have your own design system and you can from all these external sources you can just point to that source for that component and just pick out let's say the title field and this direction description field I put those on my component but the thing that uniform stores in the uniform system is not that information uniform only points for each field to where these things come from in these from these external systems so it's a very light thing that's stored and so you can actually query uniform and just get the references and then you query all these systems please don't do that you can because we're doing from then add it on top which makes it magical that I don't think any other system offers is that on the CDN Edge we enrich all of that Json that only points to stuff and so we follow the pointer query the stuff for you put it back in and then give you the result of everything which means we are enhancing whatever that very simple structure is with only pointers to Something Real on the edge and there there's a lot of smartness going on because we cache it on the edge we don't cache it in uniform we don't store that stuff we only cache it on the edge which means you can say the time to live for this source is 30 seconds and so every 30 seconds when somebody hits that endpoint on the CDN Edge or the uniform SDK does that the up the data is updated for just a few Fields you can also set up a web hook that says if in contentful I update this content type a web Hook is sent to uniform it has a little code with it of course it's so security stuff is there and then uniform will find wherever that pointer is and then and cache or Purge the cash just for those things on the CDN Edge and so when you uniform queries with the SDK that's Edge endpoint it's 15 milliseconds it's ridiculously fast and it's all cached so we don't have to connect anymore to all these systems it just happens on publish when you hit publish uniform stores the skeleton data it goes to the edge and reaches it there and then stores it well and I think while we're talking about um enrichment and Edge hinting it's probably also worth talking about personalization in that context well that also happens there yeah but that's a different type of edge though yes like and so we do have the information for the multiple variations of components that you might have but that doesn't all end up in the client so then there's another piece of edge that uniform uses especially let's say you have a next or a next app and you run it let's say on for cell or cloudflare there are Edge workers and these workers there's just little functions that you can create by using something called a middleware so every time you hit a URL um it renders the page but then it also goes through that function and you can change by streaming whatever the HTML was that was rendered and then change it back so the user gets something else like if I'm in France and you're in Canada we can both see a page differently from the same Source because you can change whatever happens whatever is rendered on that page you can change it through that middleware little Edge Handler function and that's how we do personalization which also means we have SSR based personalization through Edge handlers and I think each personalization step is like two milliseconds three milliseconds so it's ridiculously fast like you could have 15 endpoints with different cms's whatever you want on one page loads in like I don't know 35 to 50 milliseconds and then personalize it completely for just me here in the countryside in France adding another 10 milliseconds it that's just it doesn't exist and it's super cool I think it's also work if you go too deep with this yeah yeah right no it's it's pretty deep but I think it's it's interesting um to talk about because I think one of the thoughts from people moving from monolithic systems to composable approaches is oh you've got all these connections to other systems uh how do I know that I can depend on all of those and I think the you don't have to exactly that's that's an answer it doesn't it doesn't actually work that way the more stuff that we push to the edge exactly if it's just there on the edge it's kind of volatile on the edge for as long as the cache exists yep which is very interesting so we don't actually let's say you have very sensitive data right let's say you have a fashion campaign with models that are only allowed to be there for two weeks after that you get you get fined or whatever because of the the rules you have with them well imagine if uniform actually stored that data on their server then you need to make a special SLA with uniform that says okay if in these two weeks they're still there and somebody can still find these images you're screwed right that that's very special and complicated especially in Enterprise uniform doesn't even care about the data it's only and also let's say you query a whole data model from contentful right we only store the one field that you selected in the uniform interface not everything so there's no worries about having data cloned and how gdpr works with that all the complicated stuff is just not there yeah yeah no I think it's it's a really elegant approach and it kind of answers a lot of the questions that people may have about moving to a composable approach and and the dependencies on all those other systems um I would honestly say it's the hardest way to build anything like this is crazy complicated doing that like field by field cash per hardest way for us let's clarify that oh yeah not for end users it's like as a product company this is the hardest thing to do but once it works and it does for end users you have no worries because the uniform SDK even though it's that light it's only a couple of kilobytes it takes care of this stuff so you don't have to worry hey does this come from the answer for uniform and do I have to do things and of course if you wanted to we have hooks in every nuke and cranny that you can use like imagine you get um this was an example I saw recently where I was querying I think a notion database with all my conference talks because I just it's like a little database I have yeah the date that comes from notion is kind of a strange parsing that I don't like to show on my website because I want to do like 5 March 2022 in like a nice way so I need to separate things out well a data source will never have it that way so what I needed was a little Hook is like when I get that data I need to be able to change that little date field and then it goes to my component because I don't want to be changing that in my component itself because next week when I don't have dates like that yeah it makes no sense to have that kind of weird logic in my component I want data to just be like that and maybe the date field is not the best example but it's one that I actually dealt with and so uniform does have enhancers you don't have to use them at all I have not had to use one in a long time other than that one date thing so just change that parsing encode a little bit and then the data was updated and so if you wanted to you can like the idea of uniform is its agnostic super light and if you want to change something you can change literally everything which makes it one of those things that's sometimes a complicated cell because every question we can answer with it depends you want to do it sure I'll give you 15 reasons and 15 ways to do it don't because you don't actually have to but you can because that's the essence of enterprise software yep wow that was a long pitch there but it worked I think yeah no I think it helped um kind of explain you know both what we do and then also how how the SDK kind of to our Point earlier the the quality of the SDK and and what the SDK includes should really be relating very closely to what the actual software delivers and and help you enable that well and I I think I think you explained that well awesome thanks for that perfect um but at that time though I think we're nice and early yeah I think we pretty much covered everything that we needed to cover you know in some cases we've gone long in this case I think we've gone short because they're pretty simple and easy to understand well hopefully even even if the underlying concepts are a little complex exactly yeah perfect all right so I add that I I think we can probably call this one uh call this one done and I call this one Friday afternoon beer time that's that's the other reason to wrap up early Tim Tim is in Europe and you are definitely coming on Bureau o'clock only 4 P.M but what we say in where I'm from in the Netherlands if there's a five in the clock so I still have a a few like an hour I thought the Dutch would say uh bircha oh yeah we do that's the word if you're an expat that's the first word you learn all right well enjoy that and uh thanks again for joining me Tim all right bye everyone bye