The Future is Composable: Where to Start in Building for It

Hi, I'm Henry Smith and I'm a senior solutions engineer at Netlify. Today, I want to talk to you about the future of the web and composability, and where to start in building for it. One of the luxuries of my job is I get to talk to hundreds of different customers who've all gone on this journey towards composability. What we thought we'd do today is collect some of their thoughts and tips and tricks that we picked up along the way to help you on your composable journey.

When we talk about composability in the modern web we also need to think about where have we come from. Now, still monolithic applications make up a large majority of web applications out there at the moment. By monolithic we mean a series of interdependent applications from our data layer through to a web server pushing that out into a CDN and then eventually hitting requests on the browser. Now, this is all well and good and it's served us well for many, many years. But as soon as we start to try and build on this or change things in this monolithic structure it can be a real headache to pull out and change functionality and bring new things in. Because effectively it's all interdependent. So we have to check on every single layer that it's not breaking anything or making any breaking changes there.

So kubectl, or composable architecture, or JAMstack, it's got many different terms. But I like to see it in terms of this kind of build time versus runtime architecture. So what we're looking at at build time is taking our code base from our Git provider and then taking all of those backend data sources. So our CMS, our PIM system, our databases, etc. And bringing all of that through into a static site generator. This allows us to build out our site and build out all of those assets and then give us a prebuilt experience which we can then pump out globally onto our Edge network or our CDN. This now takes us into the runtime phase, so clients can go and fetch that cached data, that cached version of the site. And for any dynamic aspects that we want in our site, we can go make requests to third-party services from the client, or we can spin up serverless functions and do various bits of logic within there.

So why are people going towards this more composable route? Well firstly, it allows you to pick best in breed tools for all of these different building blocks, and this can be really powerful. It means that you can future-proof yourself by being able to plug and change between different providers, but also means that you don't have to manage as many of these services yourself, and quite often not do as good a job as someone that's dedicated to that. Also, this whole idea of statically bundling up your site and pushing it onto a CDN has a number of benefits in terms of SEO, because we have prebuilt HTML which is easy to crawl. It's also much faster, and you notice this with a JAMstack or Composable site. The speed is lightning. On top of that, the security side of things is we now no longer have a single source of truth that we're having to hit for all of our requests. This means that our surface area of attack has dramatically increased, and therefore our site becomes more secure by default. And finally, these type of architectures scale beautifully. Because we have replicas of our application cached all across the world, it means it can handle high levels of traffic and we're not having to use loads of compute and rendering and pulling out pages. This just scales up and down as required.

Now there's a bit of an Instagram versus reality when it comes to Composable, and this is a really nice view of what Composable should look like.

We've got all of our disparate services. This is for a Composable e-commerce site. All of them are interdependencies and siloed out into different areas, and then our data source is feeding into that, and then our decoupled front-end finally serving that and giving that to our end users. But the reality once you start building these kinds of Composable products can be a little bit different. You start to build in links and dependencies between the different services and the data products and all of that kind of stuff, and what you end up actually doing is building a Composable monolith. All of these different building blocks that are now interdependent on each other.

So we want to run through a few quick tips and tricks as to how to avoid that and build some really awesome Composable experiences. So the first one is federate your content layer and this is really really important. If you make sure that you have an abstraction in front of all of your content layer and everything feeds into that and plugs into it this means that when you want to bring something out and rip it out and replace it you're changing it in one single layer and everything above and below that is not affected. And this can be really powerful in terms of future proofing your application but also in terms of making sure that it's easy for developers to cross-pollinate data between different sources without having to have all of these different connectors one layer down into the data layer.

My next thing is keep it simple. Try and start off with a really small project. You can still run your legacy system side by side and take away like one simple bit, the car or the blog or something like that. Start to build that out as a composable architecture and then gradually build over time. The nature of these projects is they get more complex the more pieces you add in, but if you're really smart about building carefully and have a really clear migration pattern in terms of migrating literally one page at a time sometimes, then you can stop yourself getting into this mess and into the weeds and build it really properly from the foundations up.

My next tip is around front-end orchestration. Now this is the classic build versus buy argument. Yes, you can go and build like a really awesome CICD flow with your dev and staging environments, you know, infrastructure orchestration going and now pushing that out onto Kubernetes clusters and running production environments with failovers and then putting that all behind a CDN and having this kind of localized content through there as well. But the reality is, it's really hard to piece together, it's going to take you a long, long time, and actually, you're probably not going to get all the features and functionality that you would from the front-end orchestration tool. And that's what we're talking about, there's some super awesome frameworks out there that give you awesome rendering modes and all that kind of stuff, and to get all of that working harmoniously with things like serverless functions and edge functions is a real headache. So, this is definitely one where I would go and check out the market, see what's on offer and see what front-end orchestration tool suits you. Personal favorite of mine is serverless functions and serverless functions are your friends.

My final tip is around embracing the edge. Now, edge functions are a really, really cool thing. They're distributed logic out on the CDN edge itself and this gives you the ability to do some cool stuff around personalization, localization, authentication, things that were typically kind of more server-side or client-side. You can actually now move into an edge function and this means you get all the benefits of things like a server-side transform of your page, but you don't lose any speed. This can be really powerful, especially around that localization piece where I want to redirect or rewrite pages or manipulate the HTML itself on the edge. So, I would definitely start taking a look at this early doors and see if you can incorporate it into your project.

So, there's my five top tips. Hopefully, this has been a useful lightning talk and you've learned something a little bit out of that. Feel free to hit me up and I hope you have a great rest of your conference.