Supper Club × Headless Ecommerce with Shopify’s Josh Larson

I sure hope you're hungry.

Oh, I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Tolinski and Wes Bos attempt to use human language to converse with and pick the brains of other developers. I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax supper club.

Welcome to Syntax. This is a Supper club. We've got Shopify's Josh Larson on here to talk to us about headless ecommerce, Shopify's Hydrogen, Maybe maybe. Who knows what else will come up? And we are just doing some Canadian banter before, for the show here.

So, we are, stoked to get going. We're sponsored today by 2 awesome companies. First one is Hasura, the instant GraphQL and REST API, for your Postgres database and LightStep, the all in one incident response platform for quick recovery.

Alright.

Let's get into it. Welcome, Josh. Thanks so much for coming on. Thanks for having me. I'm super excited to to chat with y'all. Yeah. So, Where are you from? Are you from Ottawa?

I'm from Iowa.

The Midwest United States, Des Moines, Iowa. So

I'm, yeah, not Canadian, but kinda close. I just thought you were Canadian because we were talking about the the Rogers outage the other day. But assuming a lot of you I, Well, I have a lot of Canadian coworkers.

Yeah. Oh, yeah. Yeah.

Oh, that's good.

And you've been working at Shop Wait for how long? About a year and a half.

I've been at Shopify. Yeah. That's awesome. And, like, why don't you give us a a quick little rundown of of what it is you do at Shopify, and then we'll We'll dig into the nitty gritty of it. Yeah. For sure. I work,

I'm a senior staff developer at Shopify. I joined about a year and a half ago on the performance team, online store performance.

We, at Shopify are, you know, looking at our the performance of our stores pretty critically and wanting to improve those, and so there was a team that was Okay. Did that.

A few months into that role, I switched to join a new project called Hydrogen, which is a, Our our our custom storefront stack that we're we're building and have built and launched now. And so I've been working on that the last Year and a half, and, yeah, that's what I do, on a day to day basis. Right right now, I'm actually on paternity leave, so I, I I don't remember work. It's been a few weeks. Oh, thanks. So

if if I sound a little rusty, then you you know why? We're tired. It came out of retirement or not retirement, but out of paternity leave just for the center of return. Pretty cool. Yeah. That's awesome. Congrats.

Alright. So we had a couple questions, a while back about, like, headless ecommerce. Like, how would you do it? What are the pros? What are the cons of that type of stuff? And at the time, I was just like, I don't know.

I I've done a little bit of it myself. I sold many t shirts, via my Gatsby website with a with a headless solution.

But I've never like, I don't know, I never had like a good like, oh, this is the thing that you you wanna go with, right? And then around that time, Shopify sort of rolled out this thing called Hydrogen, which is kinda aiming to do exactly that. So you wanna give us a rundown of of what that is? Yeah. So,

Hydrogen is a React meta framework that lets you build custom storefronts on Shopify.

Super opinionated for Shopify.

And, it it includes kind of all the the bells and whistles you would expect when building an online store, in a custom way. So We we offer all sorts of data fetching utilities and, you know, customer, interactions and and all that sort of stuff, and performance and and everything that you would expect, with an e commerce stack. And then also Paired with hydrogen is Oxygen, our our hosting platform. So, I mean, the 2 of them go really well together, but you it's not exclusive to Oxygen, you can deploy hydrogen to Vercel or Netlify or a Docker container somewhere in the world.

Yeah. Yeah. Yeah.

So so Hydrogen ships like a, a static site or a a node server site or either or, or is it just 1 1 or the other? Yeah. So it's definitely,

like, not static, and and that's kind of a decision we made early on when building hydrogen.

Yet, like, back in well, what was last year? 2021? Yeah. We were I mean, looking at the landscape of of, you know, frameworks, you had your Gatsby, you had Next. Js, which was, Kinda leaning into incremental static regeneration, static stuff that was regenerated.

And Remix hadn't been released yet, and we were, you know, trying to figure out, okay, how do we build something? We believe that commerce is inherently dynamic. Right? We believe that in order to have a a really personalized e commerce experience, you want to have something that renders on the server. You're making a lot of, calls to your personal databases, but also Shopify's APIs on the server. And you wanna have something, that is Both performant but also designed for that.

And so we ended up building Hydrogen. Hydrogen runs, a a Node. Js runtime, but also a workers runtime. So you can deploy it To, you know, cough their workers, Netlify's Deno, and, but also a a node server running wherever Heroku that you want to. So,

one thing that I I really like about this approach is that, you know, many times that we've worked with, ecommerce, especially headless ecommerce. Do you find yourselves Making a lot of the same types of things over and over again, whether that's like a shopping cart or, we have these components that, every single ecommerce site needs.

And that's, like, the big problem in my mind with headless Ecommerce in general is the lack of integration there.

It it seems like that's one of the big problems Hydrogen is trying to solve. Do you wanna talk about Some of the the components that exist here. Yeah. No. You you touched on a really good one, which is cart. And I think that's honestly a huge value proposition,

Having something built, like a cart that works out of the box because it's kind of a complex interaction. Right? You have Totally.

You have a cart that needs to be synced with some third party API like Shopify's, storefront API. And, you have interactions When you add to cart, then you, of course, have the ability to modify quantity, remove from carts, customize line items in your cart, apply discounts potentially or do whatever sort of things that you might want to do in your custom card and then, and then go to the checkout. So, cart is included with hydrogen.

Other things that, I I think are personally super beneficial are the, Kind of the product detail page when you click on, like, a variant.

You click on, like, I want the blue shoes. So now I I know never mind. I want the red choose, and then it updates the price or it changes the button to say, oh, those are out of stock. So that interaction, like, we call it, What is it called? Like, selected options or something like that.

It can be pretty complex, and so there's a lot of logic that goes into that. It's It's literally, I think, a a hook or a provider right now, that that builds that functionality for you.

One interesting thing that We've encountered over the last 14 months of building hydrogen is that we initially had a bunch of components. And, we had these grand plans of, like, alright. We're gonna build a Super cool UI toolkit.

And, we had, like, a React provider, which is A fancy way for the folks who aren't familiar, like, to to kinda pass state all the way down to, like, nested, children.

And We had the ability to we have these components for, like, selected variant add to cart button, and it was like a really long component name space. And, We had a lot of examples of these. But as it turns out, I think they were they ended up being too rigid.

With the initial Batch of, partners and customers that started building with hydrogen had a lot of custom data needs, which makes total sense. Right? You're building Yeah. A headless storefront, you're gonna wanna do something custom. And so we were kind of pigeonholing them with these components, and then we started removing component after component after component.

And, and we were left with these really critical ones like carts and selected options, selected variants.

And And I think it we're in a really good spot now.

But the these UI components don't necessarily have to be tied to, You know, Hydrogen's meta framework. Right? Maybe you wanna take these and use them in Next. Js or in Remix.

And we're not there yet. We haven't Like, we've been really focused on the core experience, but we definitely are planning to strip them out and make them composable with other other frameworks too. Oh, yeah. That's that's really cool because people have asked us all the time, like, hey. Should I build my own ecommerce?

And my answer to that always is, like, if it's, like, simple, maybe.

But, like, once you get into it, Oh, my goodness. Does it get complex quick? Like, I did, 2 different t shirts, and I had 2 different colors of those t shirts. And like, so between those 2 things and then there's, what, 8 sizes of men's and Eight sizes of women's. And before you you realize, you have, like like, 40 different permutations of just a silly little t shirt. Like, that's not even, like, a real business that's selling real stuff. You know? It gets out of control over quickly. So because of that, my my answer is always just like, it's kind of complex, And you probably don't wanna endure that type of hurt, and that's not even touching any shipping integrations or fulfillment or Or anything like that. So Yep. What I see by this is that, like, like, sometimes you do. Like, you either go all in on, like, a Theme and the template system, and you take something that's built or or you build it from scratch. So what I see this is as sort of like a middle ground where it's like, I do want to build my own thing, Or like you said, eventually, I already have a react application that I don't want to integrate e commerce into.

So, like, What do I do with that? And and this is a set of components that will allow you to manage your cart, fetch your products, add to cart.

And it's kinda cool because, like, I was I was looking at it. It's like, well, if you wanna do your own button, you don't have to use the Shopify button. You just wrap it in the add to cart button. You put your own button inside of there, and you can still style it and and make it how however you want. Is that correct of of how I have it? Yeah. I think that would be the ideal case. Right? If If you already have an existing thing, you could drop in Shopify's,

Hydrogen UI package that we're proposing that we build and Yeah. Get some of that stuff, the the complex interactions, the UI stuff, for free, and, that would be super cool.

So my question also is, like, people are listening, like, why would you want to go headless For an e commerce, like, isn't having a Shopify storefront enough? Like, what's the benefit of going headless on this?

Yeah. That's a great question, and we get this a lot too, from folks who are asking us When is the time to go to a custom storefront or they think that they need to go headless when, really, they don't? And what we've been telling people, is Wait as long as you can. If if you're using Shopify's online store, it's it's kinda what we call it internally, but it's essentially you know, it's the the the Shopify experience that you're used to with The templates and the themes and the all the cool settings and, apps and liquid, templating customizations, That can get you that is suitable for most people.

The reason is that as soon as you go headless, especially before hydrogen and oxygen were introduced, You incurred a huge cost of development time. Now you're you you're responsible for all of your site's code. You've gotta hire developers to, not only, like, build the initial template, which, like we said, is pretty pretty complicated, but then also keep it updated. Right? As as the APIs change or as, you know, The new thing comes out or you may need to swap out a marketing hero.

You've gotta integrate with the content, probably CMS, like Sanity or Contentful, to allow other folks to update the site. And and then, of course, you gotta host the thing, and you're you gotta keep it up and add monitoring and logging and performance Metrics and it's so that's why we say, like, unless you're a big, rather large merchant with, the capability of hiring an agency or development team, the Shopify online store is is really probably what you wanna continue doing.

That said, like, developers like the 3 of us or or folks listening to this are are probably the ones who are also experimenting with it. Like, I I can write that code. Like, I can I can handle it? So there's probably that that crowd too. But, Yeah. That's what we've been focusing on right now because, with with the introduce introduction of, hydrogen and oxygen, that Penalty goes down a bit because now it's kind of like the ideal goal is is that Hydrogen and oxygen are the equivalent of liquid. Right? You just Yeah.

You click a button. You now have a storefront running on Shopify's infrastructure Just like you had with Liquid, it's it's hosting for you. It's code for you. You can tweak it as needed. And we should say for everyone listening, Liquid

A liquid is, the templating language that is used by Shopify.

I I believe it was actually created by by Toby, Of Shopify. Right? Yeah. It was. Yeah. It's cool because it's used in like, I use liquid all over the place. If I write a email for my, email newsletter, I have to template that out Liquid. It's it's very popular templating language, but, like, the next generation of that is is even more powerful.

And it's it's called JavaScript or or JSX. Right? You can write your entire store and template it out right in, in React land. Yeah. There's something about, like, components. I think this is my theory. And I don't know if you y'all agree is Liquid is decidedly not a a programming language. It's it's a templating language. It's not There's a certain limit to what you're gonna do and and what the functionality is gonna be, at least today.

One of those things is components, and, like, The the benefit that I get from working with React is that I can write components and I can reuse components across my site. I can write a really, like, scalable, maintainable system.

I don't have to copy paste a bunch of horribly nested, code.

And I really enjoy working with components. And so React is, I think, a A sensible, solution for that. But also and you look at, like I think Rails is embracing components of the view layer at some point. Laravel, The same way I I work on Laravel stuff on the side, and I really enjoy working with their component views, all server side rendered. But just that abstraction is huge.

This episode is sponsored by Hasura, which is the instant GraphQL for your data that's using Any Postgres or Postgres family of database.

You don't need to write your GraphQL server by hand anymore Because all you have to do is point Hasura to your data source and let it auto generate your GraphQL API within minutes.

You have granular authorization baked in so you can secure access to all of your data sources, databases, or any other external GraphQL API.

You can even have your own GraphQL API sources bringing into Hasura and then add complex authorization rules Down to the individual row and column level, you can also simultaneously share GraphQL and REST APIs and create Styles of APIs from one configuration to support new and existing architectures.

Because let's face it, building and maintaining your own GraphQL servers It's time consuming, and it's difficult. And with HESARA, you no longer need to do that. You can save half of that time That you would be spent building your API and maintaining it, and you can put that into actually doing real work. So sign up for HasuraCloud's free tier. It just takes a moment and you can get started. And you can get real time GraphQL instantly. So head on over to hasura.infoforward/ Free trial. You can use the coupon code, try Hasura, and you'll get 3 months of Hasura cloud standard free tier. Only the first 100 people get this, so please, head on over there right now and give this a try. Thanks so much for HESARA for sponsoring.

I have a question about, like, where does custom logic fit into this type of thing? So, let's say I had an e commerce store that was selling, like, custom mugs, and I wanted to build like a like a mug maker, in React where people can upload photos, you can slap some text On it and you can pattern stuff. And then and then when that's done, you ship it off to Shopify and and you check out.

Does That, like, custom logic would have to, at some point, happen in, like, a serverless function or on the server side.

Does that Encompass that, or was that would that be my own, my own custom dev that would be done somewhere else?

It's a great question. I and I'm not super familiar with what I'm about to tell you. So Okay.

It is, so Shopify is investing super heavily in this concept of meta fields or meta objects, and I think one of our biggest goals is to move a lot of this Kind of customize data into meta objects.

Obviously, for customizing your storefront with you know, Kind of building a a CMS within Shopify is is in our road map. Mhmm. But also, I'm not I'm the thing is I'm not sure if we're planning to, like, Support customer, you know, submitted data. Right? Like, is that the intended use case of that? If so, then that would be perfect. I think, like, having a data platform within Shopify, where that you can query and and perform mutations against in in your server components or API routes, that would be perfect. Otherwise, yeah, you're right. It'd it'd probably be your own sort of dev serverless function that you're hitting or, an s three bucket or something like that. Yeah. Yeah.

So do do you wanna take a minute to maybe, like, talk about, like, the stack behind hydrogen? I'm seeing some some fancy, like, Veet stuff. It seems like Veet, handles the server side rendering and hydration and and things like that.

Are are you guys taking advantage of any these new React APIs, any of these, like, what's the the suspense or anything like that? And just maybe talk about some of the underlying tech Behind, what what goes into hydrogen and how it works? Yeah. Absolutely.

So this was April 2021 that we started working on hydrogen.

The the tech it's interesting because what happened is Toby, our CEO, took a week and was like, okay. I need to Step aside and build a a custom storefront using modern headless tech. I just wanna see what the landscape is like. I wanna wanna test our dog food or APIs. Right? I wanna see where the holes are. And he chose Veet because that was, like, the hotness. Well, Honestly, I don't know if you even know if it was the hotness yet because it became the hotness, shortly after that.

Yeah. A year ago, it was it was hardly anything, and now it's It's exploded everywhere. Yeah. I was gonna say it's hard not to to just pick it once you once you try it because it's so good. It's so fast. It's really, really good.

Honestly, like, it was still early days for Veets. It was Veet. I think 2 had just come out, and Evan Yu had just migrated from it being a view only project to, like, an agnostic project. Right? And and that was v 2. And so that was that meant that React was supported and SSR and React was supported. And so That was the kind of the the initial who is the the base of our stack? And on top of that, we added React. You know, you just have to choose something at this point. React is super popular. We know there are a ton of Vue and Svelte and Angular and Ember developers out there, and maybe we'll we'll add some flavors in the future to support those folks. But we started with React.

Specifically, one choice we made early on was To lean into this idea of React server components. Server components had only been kind of announced as a an idea or a proposal Mhmm. In December 2020.

And they were certainly not, like, production ready. And I think what we were doing early on When building hydrogen, it's like, we were trying to find a way to promote or enforce server only data fetching with a really performant front end. And we were looking at what, you know, Next. Js did with git static props, and, we were like, gosh. Do we need to invent yet another sort of loader thing at the route level? And, like, everyone's doing it, and they have to do it, like, slightly different way. Or can we lean into this new thing called server components? And So what we did was, we just kinda went for it. And so we we reverse engineered a version of server components that worked in Vite, because the the proposal that they published was built with Webpack, and we started building our APIs around React server components. So there's this hook called use shop query in Hydrogen that you can use to fetch data and run GraphQL Queries against the storefront API and get all your product information and stuff.

That is a, a server side hook, a server only And so that runs in server components.

The data is fetched, and it's, sent to the clients using that, React serving components syntax and then your client bundle that loads in the browser, only contains JavaScript code that is used, in client components, it doesn't include any of that server side logic, and it means a lot smaller client bundles. So it also ideally means a lot faster hydration support.

This, of course, went hand in hand with React eighteen's Streaming SSR and suspense data fetching. So it was a whole bunch of, like, new experimental tech coming together at once. Yeah.

It was, Yeah. What do they they call it? Assembling a plane while you're flying it? Or Yeah. Like, you know, those dangerous metaphors. But, It's, it's been really I think it was a really good decision.

I think the the idea of React server components is like, a really good pattern. It's a good separation of concerns that we've been kinda looking for for a while. Like, this runs in the server, and I know it's only gonna run-in the server. This runs in the client.

And, it also means, I think it's gonna play well into the the, like, third party developer ecosystem in the future because the because developers can write server components. You can fetch data in those server components directly. You don't have to have a route level data loader like get static props or, loader functions in Remix.

And you can do npm install, my third party widget Mhmm. And drop in the server component in your app, and then your data's Fetched.

You don't have to wire it up. You don't have to do all that stuff. And so I think that's gonna be huge.

We have an initial set of partners working with, with us in Hydrogen, and I'm sure that is only gonna expand.

But I think that that server components bet is gonna pay off, especially right there. Interesting. Yeah. That's this is, like, the first time I've been talking to somebody who's, like, a production running server components. And you guys are not even just production running it. You're you're you have a framework built upon it, which is really cool to hear, how that all works?

This episode is also sponsored today by LightStep incident response, the all in one incident response platform for DevOps and Our ease. LightStep instant response is built on the ServiceNow platform, which is used by over 6,000 companies.

You pay for the services you actually use, not the number of the people on your team, which is important because you can scale your incident response team without adding to your bill. You get intelligent on call scheduling and escalations.

You can get the full context on your service health, active alerts, and who's on call. LightStep incident response immediately pinpoint issues and groups alerts with machine learning, reducing your time to respond. And this means less noise and more personalization for precise notifications where you can take control on declaring incidents automatically notifying the right teams. And you can get unified incident response by seamlessly orchestrating alerts and incident triage with on call scheduling across Slack, Teams, Zoom, desktop, and mobile. So what you'll want to do is head on over to lightstep.comforward/ syntax, and you'll get a free 30 day trial. Listeners of Syntax will also receive a free light step incident response t shirt after firing an alert or incident. So check it out. Are you in need of incident response? Check out lightstep.comforward/ syntax.

I I do wanna ask. You said maybe down the road like, you guys obviously are are early days in this type of stuff. You said maybe down the road, might be Hevesfelt or might maybe Vue.

I'm curious about, like, authoring a library like this. Like, How much of the code when you wrote this thing is just JavaScript functions, and how much of it is specifically React stuff? Do you have any any concept of that?

Yeah. We've done, we've had discussions about those too. And I know we've been asked like, okay. How How can we strip this down and and package it in a way that is, potentially, like, agnostic to React, Just vanilla JavaScript.

Yeah. I think it's not as much as we would have hoped. Like like, Like, the to return to the selected options example where you're selecting a red or blue shoes, That is, like it's pretty closely tied to React state management, and it's a bunch of React folks. Kidding. And so you can't, like, necessarily strip that out. You can maybe get utility functions out of it. You know? Yeah. But at what point is that gonna be actually beneficial to people? Yeah. It's yet to be seen, like, how much is, can be shared and how much of it is just bespoke per per framework.

Josh, was it you on somebody on Twitter? I was asking when the Deno, Node, Cloudflare, Vercel and Shopify rolled out the, like, JavaScript interop committee.

Are you familiar with I want Yeah. Winter CG. Second here. Winter CG. Yeah. So I was like at the time, I was like like, well, I don't know. Like, I get it. I get why Cloudflare would want to be a part of this committee, because they want, they want it to sort of work everywhere. Right? And and I was like, but why would Shopify want to be on this? And I'm not sure if it's you or somebody else on your team said, like, we just want this to work literally everywhere.

So Is that something that you need to, like, pay attention to? Are there specific APIs that you're not allowed to touch so that you can deploy this thing to Deno or to Netlify

or to into Node. Like, this is not just I I think this is not just a Node environment. Is that right? Right. Yeah. I mean, it's such a it's an interesting topic, especially building a framework in, you know, this day and age where you have all these different deployment targets. And What? Last week, bun bun js was introduced, and so you they just keep coming. Right? So It's, super interesting. The this kinda goes back to to Oxygen. Right? We started building oxygen around the same time we started building hydrogen. And we initially built oxygen using, v eight isolates, which is kind of the same sort of backing tech that Kovler uses.

And they're it's a workers' runtime, quote unquote, Where you have, more of a browser like JavaScript API environment than a Node. Js API environment. And so The tricky thing about that is you are generally probably gonna be developing locally in a node, Node JS environment.

Yeah. That's what Vete uses. Right? And it makes sense if you wanna deploy hydrogen to node as well because then it's the same, but then you switch to a different environment, Oh, and and it goes to kind of a build step to package it up for, like, a single file worker.

And so, yeah, to to answer your question, you do have to be conscious of that. Like, oh, I can't call.

I don't know. I can't import FS, right, if I'm planning to deploy to, To, a worker's runtime.

What ended up happening is that we found out that's, like, building A our own hosting platform is quite difficult, and I think this is definitely not off the table, in the long run. But we partnered with Cloudflare, with their new kind of workers For platforms, announcement that they they had a few months ago. Okay. And so, yeah, oxygen is is powered in a lot in part by Cloudflare. And,

yeah. No. That makes sense.

It's really cool that it runs on Cloudflare because I was curious about that in terms of, like, this is like a big This is like a big framework and they're saying I want it to work literally everywhere. And if you if you are deploying Durkka to Cloudflare, like, Maybe we should explain 1 step back for our our listeners is that, and we've talked about this. Go back and listen to the Edge function shows that we've done. But essentially is that there are more and more frequently there are other JavaScript environments than your browser And the server and node, there is even in the browser alone, there is there's there's workers. Right? But now there is, Dino, and then there's Bun, and Cloudflare has its own sauce.

Bloomberg has its own version. So there's all these different environments. And the idea is it's like, well, this is going to be a big pain in the butt if things don't really work well across, across all of it. So the idea is that we try to shy away from using, specific APIs that don't work everywhere and just stick to a set of APIs that will work across

or at least use adapters so that they'll they'll work in there. So, Yeah. That's cool. So the the winter CG, I think, is kind of the answer to that. Right? I forget what it's called. Like, web interoperable runtime, I don't see a group. I don't know what it is. But so my hydrogen, teammate, Brett Little, I think he's the one who talked to you on Twitter about Okay. Why why we're part of that, but he's he's he's part of that.

And, some examples are, how do you do, Like, runtime variables, right, in in every environment. Can we build a standards, you know, approach to that? So if you're a node, you use process dot m. If If you're in CallFire workers, you get them, like, passed to you as a callback function to your fetch handler.

Deno, I think you can use Deno dotm or something. And so it's different, it makes it very difficult to build a a standard around that if you're a framework author like Hydrogen.

So can we come up with a new API That addresses those needs. Or, another example is, using the, you know, their Request response objects, which is kinda the the web API interface that you would expect in a Cloudflare Worker, Those were designed for use in the browser. And so, certain things like I can't remember. I feel like response dot Set cookie.

Yeah. You're not supposed to be able to do that in a browser. Mhmm. But you want to in a server, and so that makes like, if you're using Depending on what shim you're using or what runtime you're using, your results might be differently if you're trying to set cookies on an outgoing response. And so that's that's,

The sort of thing that the the the working group is attempting to address, and I'm super excited to see, you know, what they come up with. I was just looking at a list of companies that were part of the Winter CG, and there's 2 new ones since we last talked about it. There's Agalia, which, we're gonna have some folks from Magalia on. They work they work primarily on WebKit, and things like WebKit on PlayStation and whatnot. And bite dance. Do you know who bite dance is, Scott? TikTok. Yeah. Yeah. So they I don't know What Really? What horse TikTok has in this, but I'm very curious. I would assume they have a lot of horses in that. Yeah. Yeah. I guess they got Host one of the largest websites in the entire world. So Right. They're probably so somebody from, TikTok, Please get at us. We would love to have you on to talk about how you're using like, what JavaScript you're using to host your TikToks. Yeah.

Yeah. I would I would be interested in that too. Yeah. Oh, let's talk about integrations. So,

that's another question I I I had from people is that, like, should you have, like, a CMS and like a and like a, what's it called? E commerce platform. Right. Like, if you have an e commerce platform because shop Shopify can kind of be your website, but not really. Most people will have, like, a separate,