What does a technical architect who's seen it all see when they look at the modern digital commerce landscape? High Velocity's own Principal Technical Architect Adam Clason walks us through the deep lore of react and Next.js, as well as some potential gotchas coding for composable. Also are monoliths that bad?

I'm Justin Burrows. This is Commerce Chats by High Velocity.

JB: Hi, this is Justin Burrows with Commerce chats from High Velocity. I'm joined with Adam Clason. Adam, why don't you, introduce yourself and tell us what you do?

AC: Good morning. Justin. I've been working at High Velocity for a little over a year. I'm a code guy, software developer. I've been working on this composable app.

JB: And, is it true that you're the principal technical architect?

AC: Tae been, you know, putting out suggestions. So that's that's somewhere in that vicinity.

JB: Well, I'm the hype man, so I feel you.

AC: Did you come up with your own title?

JB: Actually I did, yeah. Because I was trying to think of, like what I would describe, like, I work on product, but then I also do a lot of, like, research and a lot of interactions with people. And I just never like any title that had the word evangelist in it just didn't, seems very 2010 to me.

AC: It reminds me of like a Microsoft. Like I think it was like a Microsoft thing. They had, like, all these evangelists.

JB: Yeah. And you've got like or your, your CWO and you just have to think about like, what is, what are they the chief officer of? And it's like I'm the, you know, Chief Wombat officer. And it's like, okay, so I figured it would be irreverent but still descriptive of the actual the actual job title.

AC: Tae definitely has the energy of improvisation where it's like. Yes, and... So if you pitch an idea, you better be prepared because it's like, yes, this is. Yes, let's go. Let's do something like that. So which is good, but can also be intimidating. You know, you have to think about what you're going to say because then you're going to end up doing it. You're going to be moving rubber tree plants, I think it's good to be able to kind of explore that. I worked on the integrator side for a long time, and I think one of the interesting things about working in product is you get to take time to think, how would I do this if I wanted to do it? And I think that's a different dynamic and, you know, exercises a different part of your brain.

JB: It's totally different than someone coming to you with a set of requirements and what they want, and then you figure out how to, you know, build that versus kind of starting with, in an ideal world, how would you go about building this

AC: Not many greenfield, ecommerce projects out there these days. You know, you're always that's true, implementing or building something. But now you started working on a platform, right.

JB: Like I.

AC: Yeah. No, I started, on work, like working as a developer, on a custom dotnet e-commerce platform. So that was kind of home grown by, the company that I started working for out of college. they had a large, retailer on there, for a number of years. So Yeah, that's how I got my start. Was not in like a, like a Salesforce or a Shopify. It was kind of a homemade thing.

JB: How did you progress from. Sorry. Go ahead. No.

AC: Go ahead. Okay. It wasn't a greenfield for me when I got there. It was already pretty mature. But originally it was for that for that company.

JB: And what was your journey from there starting on this custom. Net application to here.

AC: We had that client on this custom. Net platform and back in the Demandware days, which was, I don't know, 2013 or 14, that client, decided to shift to Demandware off of this custom platform. They had grown, and they took us with them essentially. So our team that had worked on this custom .Net platform, some of us, learned Demandware in order to help with this migration and then the subsequent support work. so that is how I ended up on a platform and on Demandware soon to be Commerce Cloud. And then so I worked for a variety of clients doing that, over the next several years. And then, Tae gave me the opportunity to start on composable doing some composable support and implementation work, using Next.js and commerce tools. So that was kind of a, an opportunity for me to get off of, the platform work, which is good. And it was a tool, that I did enjoy at the time. But, I did kind of want to get back to, more general web development and not be super pigeonholed into, like, I know this one platform so composable is kind of a, a natural way to, to make that jump. so did some support a implementation on composable, and, and now here we are at High velocity. yeah. Building this storefront app.

JB: So you mentioned Next.js. Could you for us liberal arts people could you describe a little bit of what Next.js is and react? JS I'm trying to understand like I my understanding is that react JS is part or is the undergirding of Next.js, but they're separate things. Could you talk about that?

AC: I mean I think that's broadly right. react was created by Facebook. initially it's open source. But so it was created by Facebook because, you know Facebook was originally built on this PHP, system that is very server driven. So every time you make an interaction or you, you interact with a page, you kind of naturally have to reload the whole page or do some like kind of, funky Ajax stuff to add client side interactivity. So, you know, if you, if you like a, a post on Facebook, it doesn't reload the whole page. Right. it's a dynamic, you know, an interactive interface. So Facebook, built react kind of to, handle that problem because, it was a little bit of a Wild West, with like PHP and jQuery being kind of the old way of doing it, which can get really complicated when you have a highly interactive interface pretty quickly. So Facebook built react, which is like a front end call it like a rendering framework. So it allows you to more declaratively make user interfaces where you can say, make a change in, in one spot and have that this framework. Take care of Rerendering your app. So that all of the consequences of that change are displayed. Right. So an example in e-commerce would be you add to cart, you know, on a PDP and the the cart icon updates and then it potentially shows a fly out with what's your new cart? So that's kind of a reactive interface in e-commerce. but obviously it's a lot more broad than that. So react kind of enables that and makes it a lot easier than maybe it used to be. and then Next.js is what they would call a meta framework for react. So react doesn't handle by itself server side rendering. So if you would just use a bare bones react app, and you visit it for the first time by itself, it would be blank and then you'd have to wait for the react app to load in your browser and then show you the app, which obviously isn't ideal for things like e-commerce, where you you want the page to be rendered on the server for SEO reasons and for user experience reasons. So there's a lot of these meta frameworks around react that enable this server side rendering. And Next.js is one of those. So for example, remix is another one that, I believe, Shopify uses in some of their apps. And then there's, there's solid, there's a number of them. Well, solid isn't technically react, but there is a number of these meta frameworks that do this. it introduces a lot of complexity, server side rendering and app. so these frameworks are kind of a way of handling that.

JB: I'm intuiting here that there is server side rendering and then there is client side rendering. Would that be the other part to that. Yeah

AC: So react by itself is only client side rendering. and then you add these meta frameworks to give you the server side rendering. Then plus it gets to the client side and it still is a fully interactive react app. So you still have the client side rendering, but you get that initial render when someone visits a page so you see the full web page when you go there, instead of waiting for the react app to render and load on the client side, would that be kind of like, like a cached page or something like that? Like for the first load I'm trying to understand, like you render it, it's. It's similar to it doesn't necessarily come like a cache page. just because something is server side rendering doesn't actually necessarily mean it's cached. So, if you visited a, my account page, say that has all of your specific user information, a server rendering framework could generate that page on the server dynamically for you and give it to you, outside of any kind of cache, a cache would be taking a page or a section of a page and delivering the HTML to you. kind of either regardless of the user or based on a particular segment.

JB: Why would you have a server side rendering versus client side rendering? But you mentioned SEO is one of those, what did those server side rendered pages do that client rendered pages aren't.

AC: Yeah. so obviously SEO is a big one. essentially what you were talking about is if you don't have server rendering, you have to wait for the JavaScript, the scripts in the browser to show the page and the consequences of that, from a user experience perspective, are pretty big as well. so you'd have to the UI would be popping in as react is able to load the data. and then you also have to you have to have endpoints like a server side endpoint that, the react app would be talking to in order to actually hydrate the app. so you kind of would split it into two segments, because the react app by itself doesn't have the data that it needs to say, you know, render stuff from the CMS or from the commerce provider, you would have to expose services that the react app can call to get the data it needs to render the app. And so as it does that, it needs to wait for that data to come back and in the meantime, you have to how do you show a UI when you don't have any of the data for it? you either, you know, show a lot of loading spinners or something blank, and then you allow things to pop in. it makes for a poor experience for users. especially on mobile and slower internet connections. You don't really know, what's going to be popping into the UI. Click a button. You didn't mean to click. or you just miss an entire content of the page before you go to the next one, because you didn't know that something else is going to be loading in. Server side rendering is pretty much assumed for the most part on things that aren't like a dashboard app. It's not like not doing any server side rendering isn't really viable for most websites.

JB: So I know that we were talking about server components. how do server components. And I believe that's part of react. How do server server components, play into to the framework.

AC: Yeah. so this server side rendering concept has you know, it's helped a lot with the user experience and enables you to, you know, deliver a fully baked web page to the client, but also has introduced a number of problems with how your data loads. So since it's rendering as a react app, most of these server, uh, server side rendering frameworks like Next.js, before server components, you would have an opportunity at the route level. So like before the react app starts to render on the server side, you'd have an opportunity like before that to get all of the data that you might need for that route or to fulfill that request. So just to say if you're talking about the home page, you as a user, you go to the home page, Next.js before server components would say, okay, what's I need to give this person the home page. And the first step of that, before rendering the app would be okay, what data do I need for the home page? And maybe you would call the CMS to get that data. Um and then from there you would pass that, um, CMS data to the react app, essentially. And now the react app has the data it needs to render on the server side, before it, you know, goes as a fully baked page to the client. One of the issues with that is you have that, that top level opportunity to load the data. But after that, you would be relying on like a client side, fetch. So just to give an example, if you figured out the content that you needed on the home page from the CMS, at that top in the route loader, that top level before the react app renders, then say you are starting to render the home page and you realize, oh, this home page has product tiles. They configured product tiles from the CMS. They want those to show in a grid. You obviously probably need some data from the commerce vendor in order to render those product tiles, but you kind of past the point where you can load data, on the server side. So you're left with, some kind of what I maybe I'd call kind of hacky options to solve that problem. one of them would be just to load a shell of the product tiles and on the client side, fetch the the extra data you need from the commerce vendor that does introduce that problem of, you have to show some kind of loading spinner and wait for things to load in, which isn't the ideal user experience. and the other option would be in the root level loader. You'd have to look through all the content and figure out like what is all of the data I possibly will need to render this home page. so essentially in the loader, you'd have to figure out which components are going to render because and that will help you to figure out what data you need. which is obviously pretty clumsy because you have to know a lot about the UI on the back end to figure out, like, oh, they're going to render a product tile. And so I need to go to the commerce vendor and fetch the commerce data. it it introduces a lot of coupling potentially, and a lot of complexity. when you have to load it that way.

JB: So coupling is bad.

AC: Yeah. Especially I think in composable, the more complexity you have there. and add to that, with composable, you have multiple vendors happening, and you'd ideally like to be able to swap out vendors in the future if you needed to. And the reality is, if you have this kind of, loading pattern that can be, extra difficult.

JB: Is it? Do you find yourself, like walking into potential traps when you're developing? Uh, like, were you walking into a tight coupling of, of, I guess, what services like where it's like you could do it and it's like it might be easier, but it's going to end in tears. Do you face those types of I mean, that's that's software development pretty much.

AC: It's like I can solve this problem for today. Um, like, you know, if you're doing an implementation with, say, commerce tools and appliances, your CMS, you can pretty easily build a page and just assume a lot of stuff about compliance and a lot of stuff about commercetools. But, uh, you know, you question the composability there because you've built this all very, um, based around which vendors you have. So if you try to untangle that in the future and say, oh, we're going to switch to Contentful, uh, it's, it's not going to be much easier than just replatforming at that point. Yeah. Potentially.

JB: Yeah. I mean, I've, I've seen it happen so many times. And I mean, I understand it, I understand why, you know, you've got a deadline, you've got some. That's part of the reason that being a somebody who's doing like an implementation of an existing system can be challenging is that this is not, I call this not best practice, just it's like not a strong enough word. You know, this is like, this is you're gonna rue this day that you made this decision. But a lot of times you're just in a place where it's like, put it in the CSV. Let's go. We're just gonna have to update this in five different places. Uh, industries. This because we have to be up. Uh, yeah. That's because of decisions that happened six months beforehand.

AC: And, you know, it's it's especially a problem with composable because with when you're on, you know, a commerce platform, they kind of set things up for you in a way that's like you can kind of get away with a lot more, um, like you can it's they organize things in such a way that it'll be a little bit easier to untangle if you do make changes in the future, whereas with composable, you have a lot more rope to screw it up. And you can really get yourself into a world of hurt, because you do have all this freedom and composability, which is great. But um, also, you know, can, uh, open some doors to some problems that maybe you didn't have with, uh, a platform approach.

JB: You mentioned before, uh, routing layer. What is the routing layer?

AC: Yeah. So I was talking, I was referring to like the, the, data loading pattern, which for a lot of these react meta frameworks that we were talking about, like Remix or Next.js, you had it's the patterns that they establish for how you can load your data on the server side before the react app renders. so for most of these, it's at the it's at the route level. So that's where the routing comes in where it's like, okay, for remix, I went to the PDP. Now I have a root level loader that I can use, which is on the server side. I know I'm on the PDP. Okay. What data do I need for my react app to run to render the PDP root So that's kind of the that's that's the data loading pattern. The larger the problem with the root level loading pattern is more the, that you have to get everything there. And then once you start rendering actual components, it's since those are those need to be fully renderable in the browser, you can't have server side stuff inside of them. So once you've passed that, that server to client boundary, after you've loaded your root data, you can't load any more data from a server side before that would be delivered as a full web page. So that's kind of where that the one of the weaknesses of that data loading pattern. We talked about some of the data loading pattern or problems, uh, with, with Next.js before server components. Mhm. Um, and Some of the problems that this introduces, particularly for a composable storefront. But I don't think we got to, how to server components in their role, in kind of mitigating some of that. So server components are pretty new, uh, over the last couple of years. And they kind of allow you to compose, components in a way where you can mix in, you can have, stuff happening on the server inside of effectively inside of your react app. Uh, so this for composable. I think the biggest benefit of this is, um, it allows you to kind of build things in a more component based and modular way without having to, um, deal with that complicated loading pattern where you have to figure out all of the data that you're going to need, and figuring out all that data you're going to need is especially problematic for a composable, because you potentially have 3 or 4 vendors that you're talking to for one page. And so if you're having to load all of your data in that one spot, um, it's hard to hard to do that in a simple way and to keep those vendors not super coupled to each other. So what server components would allow you to do is instead of having to load just in that one spot, you have more opportunities where, you know, say the example that we've been talking about, where you have a page from a CMS where they're saying an appliance, where they're dropping components in and, you know, they've added a couple of banners, and then they also add a grid with product tiles. So with server components would allow you to do is as you're rendering that home page, um, you get to the point where you say, oh, I see that they want product tiles here, and they've configured say what SKUs they want in the CMS. The server component architecture would allow you to at that point, then fetch the data from your commerce provider to, uh, you know, get whatever product data you need for that tile. Um, so you kind of naturally have more of an opportunity to keep those things a little bit more decoupled. Whereas if you're loading it at the top level of your of every route, you really have to combine them, um, or figure out when there's commerce data inside of your content, um, which means your data loading is very tied to how the content is configured, which is obviously a challenge. I don't know.

JB: Now, you mentioned before you've worked both in the monolith area, the monolith framework for, architecture. You worked in kind of more composable or headless, whatever you want to call it, architectures. But I was surprised we were talking earlier. You don't necessarily have all bad things to say about monolithic architecture. Could you talk about what it is you you you mean we all have that sense of, nostalgia for old systems that maybe did certain things a lot better? What was what were your thoughts on that?

AC: Oh, no, I mean, I, I think they for sure have their place and what I was saying earlier, they do give you a good base, and a good starting point where it's a lot more difficult to really botch things. you know, they set up, you know, an API essentially for how you deal with your commerce store. And, sure, you can mess that up. but with the restrictions that they provide, they also kind of keep you in that box a little bit where you don't make really bad decisions, or they make the bad decisions a little bit harder to do. harder to make, I should say. Whereas with, you know, composable, you could probably start find some reference store to start with. but the freedom that you get also opens these possibilities of, getting yourself into a mess. so that's definitely an issue in composable. And then also, I think a lot of the react architecture has exposed some of these other problems that we were talking about with how you load your data. whereas these monoliths were more server oriented. So you didn't have to worry so much about this server client boundary. It's like you can load data you want anywhere because the whole thing is rendered on the server. And so it there's some, some, some good simplicity there. I think it's not very customizable, like you said there, there are things that it prevents you unless you make great and innovative effort. It prevents you from making certain mistakes. Although I've known. Yeah, I've known, I've known a few people. I might have been one of them myself that have gone to remarkable lengths to make a mistake in a monolithic architecture.

JB: we all have for sure.

AC: It's certainly. It's one of those. It's those one, One of those Balancing acts of constraint as opportunity where, you know, if I can live with the constraints of this system, there's a there's a trade off there. I mean it can it actually makes things more, you know, predictable like you said. But you're also kind of in that, in that little framework. And I wonder, you know, it's always, it's hard to tell someone, you know, that they can't have the unicorn, though, but sometimes it's necessary. Yeah. I mean, these platforms, you know, they are built over a long period of time by people really experienced. And they, they know a lot about what problems there are with, you know, enterprise commerce store. So and they've established kind of, the, the general solutions to those in a, you know, a straightforward way to customize. I think, you know, we talked a little bit about some of the weaknesses of that. I mean, one of them is the like the your constraint to the decisions of the monolith, for certain features and how they've implemented those features. Just to take, for example, search. So if you're on Commerce Cloud, you know they have their search index, and it has its own capabilities that, you know, Salesforce has developed over a period of time. And, you know, those are great. but you are kind of constrained to how Salesforce has decided to do and manage search. Whereas with composable, you have more freedom to say, okay, for my brand or my company. Algolia provides certain features that enable a new customer experience that I would do either been really difficult to develop using the Salesforce search capabilities, or you'd have to, you know, somehow extend it to not use them. and this selection of a of different vendors for what they're good at is kind of what, to me, composable is one of the main benefits of composable.

JB: All right. Adam Clason covered it all.

JB: Adam Clason, Technical Architect, at High Velocity. Thank you for your commerce chat today. And I appreciate you walking through, uh, composable and your journey, in development and, uh, hope to talk to you again soon. Okay.

AC: Yeah. Thank you.

JB: All right. Cheers.

AC: Talk to you later.

JB: Thank you to Principal Technical Architect Adam Clason for joining us this week. Join us for our next episode when we talk to the principal UX architect at Stone rooster, Josh Jensen. Until then, I wish you an ice cold emotional support seltzer in your fridge, genuine Vermont maple syrup on your pancakes, and high velocity.