On this podcast episode, David and I continue our discussion of the power of composable architectures. We continue discussing how Shopify now fits into this space. We get into the questions around complex content publishing that augments the sales of complex products. We talk about what 'new technology' means in 2023 as far as Solspace is concerned. This includes micro services, serverless tools, edge computing, CDNs, and the like.
[Music] Welcome to the Solspace Podcast. Thanks for listening.
Mitchell: Welcome back to the Solspace podcast. Thanks for tuning in again. This is a follow-up episode to a conversation I'm having with David Estrada from my team, Solspace team. We're talking about headless Shopify.
So a month or so ago, David put together just a demo of what headless Shopify would be, like what's involved, how quick can you build it, what's it capable of, how well has it been put together. Because we were sort of exploring the idea of how can you use Shopify to help our clients, our clients being B2B commerce clients, industrial manufacturing clients, people who sell expensive stuff that's highly configurable and complex, and for whom the buying experience is high stakes. Like you’ve got to get that purchase right because it's going to go into your factory and it's either going to assemble the widgets or it's not based on what you do in your purchase process. So can Shopify help at all?
And why Shopify? One of the reasons that we are exploring Shopify and talking about it is it's our philosophy at Solspace that you ought to fire bullets before you fire cannonballs. This is a Jim Collins idea. So the idea is that in web development, you should position yourself to try out ideas, get them in front of your customers, watch them succeed or fail, and adapt and modify over time. Fortunately, the most recent developments in web technology really support this approach. It's no longer the case that you have to move from one giant monolithic system to another and take 18 months to do it and spend tons of money to make it happen. You can move in gradual steps now and you can stay that way. It can be a permanent attitude that you take about your web development and your digital presence.
So in the previous episode, we were talking about Shopify stack and their headless stack in particular. And one thing I was asking David was of the things you've explored in Shopify. The question I have is how inexpensively, quickly, and easily can you start moving your business onto Shopify? For example, if you wanted to go headless Shopify because you like the concepts of the componentized architecture that the underlying React framework gives you, do you have to go Shopify Plus? Do you have to spend $2,000 a month to get that platform or can you try it out less expensively?
So David, maybe you can talk about your experiments in that space.
David: Sure. Yeah, you can try headless, but in a light way, if you will, and there's going to be some restrictions for you, but definitely in order to, let's say you want to present a demo to your company so we can go ahead and utilize the free plan on Shopify in order to build you a demo in no time, which is going to exemplify what are the differences between monolithic applications and headless applications in Shopify. So you can experience firsthand, if you will, how the improvement and the flexibility that this new way of building an e-commerce platform is going to benefit your company.
Mitchell: So one of the limitations if you don't go with Shopify Plus, but you want to try out the idea and give yourself an on-ramp to adopt and have your customers potentially adopt, is to go with a smaller level plan, turn on GraphQL, enable the ability to talk to this Shopify API to get catalog data out of the system. But if you're going to purchase, you have to bounce the customer back to Shopify to a normal old-school Shopify payment page to check out. That's fine for an experiment. It's fine for a trial for three months to see if some customers respond.
In fact, you could build such a store trying out the idea in order to give your team the opportunity to experience what it's like to manage their product catalog inside Shopify's interface, a pretty friendly interface as far as I'm concerned for the price point. So you get that experience of trying that out and then you get the experience of trying some of these ideas out in front of your customers. And you can send a subset of customers like have a handful of your favorite most friendly customers who like to try new stuff out, bounce them to a subdomain of your website that's not necessarily publicly known. You can try this idea out, get some feedback. What matters is that you've built a real system using real technology that has real SKUs that has the capability of exchanging real money.
Do this as a trial, it can be useful. So there's an answer to that question. How small can I start? One of the frustrations I've been having as I'm looking at other platforms to bring to bear to solve some of our client problems is so many of them want you to either, they want you to go from zero to enterprise like that. There's no on-ramp. It's either they want to crowd out the smaller, medium-sized players, and there's only room for enterprise. What happens is you can't try anything. You can't try experiments. You can't explore. If you have to present a six-figure check before you can get into some of the technology, I can't help those people adopt that stuff. We have to have an on-ramp. So with respect to headless Shopify, you create the conditions where you can have sort of a headless environment that you spin up for a client so they can try something out. They can run a part of their store on a headless Shopify store and continue to run their regular sales process digitally where it is and they can gradually transition.
So we were talking about the tech stack David that Shopify has put out to support their headless architecture. We talked about Hydrogen, which is this packaging of their spin on the React framework, and then Oxygen, which is their sort of edge optimized. Do you happen to know if there's any serverless capability built into oxygen by chance? I haven't checked.
David: No, I haven't checked that as well.
Mitchell: Okay. I don't know either. So at any rate, you have Hydrogen and Oxygen, but there's Remix too. So what is Remix?
David: Remix is a web framework that allows you to build sites with performance and speed in mind.
Mitchell: So what volume of traffic? What kind of, like, what's the threshold for this?
David: Shopify on a blog article that I read, it says that it can basically, the bottleneck will be the backend, but in terms of how much traffic, as far as I research, I don't see any bottleneck framework, it's basically the bottleneck will be the backend, which is, in this case, Shopify. But Shopify, I don't know, can handle a lot of traffic. They handle a lot of big clients, such as Adidas or what else, and without breaking a sweat, if you will.
Mitchell: Okay. So you have Hydrogen, Oxygen, Remix, am I missing any parts of the tech stack?
David No, actually, Remix is part of it, part of this Hydrogen framework that they put out. Initially, they started with Hydrogen being just a React, plus some custom functionality that Hydrogen provided, but now they have integrated Remix since they purchased Remix. So they have integrated Remix into the whole package, in terms of clarity becomes Hydrogen. So Hydrogen encapsulates Remix and Remix encapsulates React.
Mitchell: I was reading an article before this podcast recording that as far as like flavors of React or React framework, Next.js is considered the most popular. Remix is considered the next most popular as far as developer tools using React, you know, under load. I have no idea what the difference is, and I don't even know if our kind of clients who don't necessarily see that level of traffic load need that additional layer of performance beyond just what you can get with, you know, properly cached and CD and React components. But that's a problem for another day. At least it's there. This is one of the selling points is that if you move into a space where you need that level of performance or you move into a more multinational space, you know, as a b2b vendor, then you will see greater performance if you've adopted an architecture that's more capable of scaling without having to do that much extra to get there. So that's advantageous in this architecture.
What about this problem I was presenting in the last, the previous, episode where I was talking about how a lot of our clients need to support the sales cycle, the sales pipeline with really advanced and intensive content development? What are your opinions about what sorts of CMSs you would want to use alongside a Shopify store to support the education in sales of more complex types of products?
David: CMSs that don't have e-commerce support or just a CMS for handling content?
Mitchell: Yeah, it's mainly a content question or can you do it in Shopify? Can you build complex content-oriented pages in Shopify?
David: Pretty good question. I mean up to a point you can Shopify allows you to have pages like just any regular CMS world however the level of content strategy that you can do there is debatable. So what other platforms can we use? We are a Craft shop, so definitely we can suggest Craft in there to the mix. And use GraphQL in Craft in order to make calls to the API and get content. So if you will, you can manage your blog pages and any other pages that do not require any commerce. And thankfully, because we're using Remix or Hydrogen, we can consume content from the outside world. And it doesn't matter where that content is located at. It basically, we just say from this point, we want to consume the blog and from this point, we need to handle all the transactions that are our e-commerce transactions, for instance. So we can consume content from different parts.
That's one of the flexibilities that headless gives to us. And last conversation we were talking about as well in Meilisearch. So let's say that we want to integrate Meilisearch with this. We can also do that. So you see, it starts giving you all the flexibility that you need in order to start adding bits and pieces from different technologies, take advantage of these strong points for those technologies. And consume all of them inside of one app.
Mitchell: And this plays to our specific opinion and position about how you should adopt web technology, which is to say, you don't have to choose the giant single system that does everything. There's no such thing anymore. Never was really, honestly. It was always a sham. But now, legit, you can bring in multiple different types of tools to solve a given client's problem. And like you said, you could include Meilisearch as part of the solution set. If somehow Algolia makes a better case for solving that problem than Meilisearch, you swap it out. Now swap it out, it's not like a weekend job, but it's not difficult like it used to be because if everything is, is it headless to begin with? And you're pulling from various APIs and data sources to compose the page, you arguably just change the pointer, you change the URL endpoint to go get the data from another place.
You know, imagine you use Contentful and, you know, your team loves Contentful and then the Director of Marketing gets promoted and goes to another place. Now there's a new Director of Marketing and a new couple of content editors and they hate Contentful. They want to go use, you know, Strapi, or they want to have a headless Craft instance set up. That's their preferred environment or, you know, WordPress for that matter. So they can have that you just transition, hopefully, you're on GraphQL. That's sort of a standard API structure for consuming and distributing this headless content. You just make that change and you swap it out. So you have options now you called it future-proof in the previous episode, and I'm a little nervous about making that kind of promise to someone, but you're a lot closer to that concept of future-proofing your website.
David: Definitely, and remember, it's like a decentralized system if you want to think about it this way. So the more decentralized you are then the more the ability to be flexible and be able to swap things that don't work for your needs.
Mitchell: We had, still have, a client, but they went through a cycle where they brought in like a full-time employee to take ownership of the .com website and this person decided this would be the optimal client to convert to a headless architecture. And this was when the concept was new. This was like four or five years ago. Put new in air quotes. For me, new is the technology is up and running, and it's barely at the point of being reliable now. Like you can reliably build on it. There's people using it who are talking about it on Stack Exchange. It's performant. It doesn't crash. It's not a beta anymore. So it's still new for my standards. So this developer was brought in as a full-timer in-house. And this person thought, “Yo, this is a great opportunity to try out all his headless stuff.” So he built this big complicated headless stack. And the client hated it. The reason the client hated it is it was so brittle. So the problem with deploying headless architectures is you have to run all these, you know, arguably have to run all these build scripts to get your changes to the React architecture that you've put in place up onto the cloud. Or up onto the servers or up onto the edge or whatever the case may be. So they were really frustrated by this because it was brittle. It broke easily. It was hard to change things. It took forever to get stuff done because it had been architected poorly, arguably because it was new at the time. And the best sort of best practices were not yet defined.
Do you have anything to say about the state of headless and composable architectures now with regard to, are they brittle? Are they stable? Can any self-respecting web developer who understands JavaScript and some React, can they pick it up and run with it? What do you think about that?
David: To me, they are stable now. If you asked me this question back in 2014-15, yeah, I would have my hesitations such as the ones that you already mentioned. But now I can comfortably say that they are stable now.
Mitchell: So what's changed?
David: Well, adoption, that's one thing. The other is that you can see more big companies behind this, such as Shopify. So previously, it was just a handful of companies, maybe, but not as big as these companies. Remember that Shopify is basically its user base, it's people that want to do things on the web, but also their documentation, and also it's very friendly for developers. So they know that having this relationship with developers is going to help them in the long run, so they create really good documentation. That's why they have invested heavily in this Remix and React and Hydrogen infrastructure in order to make the developer's life easier if you will. So yeah, definitely. And remember, back then GraphQL was also part of that shift because we were coming from just APIs, like the REST APIs. Nowadays, GraphQL is considered some sort of a standard. So there's always two camps, like the REST APIs and the GraphQL APIs. But yeah, definitely now the adoption of all of these technologies that work behind the scenes on a headless site, they are right there where there's massive adoption for all of this. React is the number one framework nowadays that is one of the most used right after Vue.js.
Mitchell: Oh, Vue is up there in the running?
David: Vue is the second one, but React it's been the first for a long time.
Mitchell: Do you remember a time when there were not job titles like Chief of Developer Experience or VP of Developer Experience, that kind of thing? I certainly do. That's a relatively new term. But it goes to the point of what you were saying that a lot of these larger enterprises who are putting out tools like this are prioritizing the developer experience for the reason that if they can give us what we need, we can give our clients what they need. In some ways, the web has gotten simpler, like you got Squarespace, you got Wix, you got WordPress to solve simple problems, but the complicated problems have gotten much more complicated. And so you need a professional to get in there and help you out, and when we can argue for tools that are strong on the developer experience, then that means you're closer to the concept of future proof.
David: Yeah, definitely. And remember, now these platforms such as Oxygen and Shopify, they are decentralized. If you will, you can think about it as decentralized servers. So, they are put in different locations, as opposed to when you have your normal WordPress site that you only rely on one server to handle all the traffic. And eventually, if you grow that server, it has its limitations, right?
Mitchell: Well, this has been a good discussion. I think we talked about the stack. I tried to keep us out of the weeds too much technically, but also get in there so that we could answer some questions. And we're talking about 2023, almost 2024, and we're running an era where there's a concept of edge computing, which is to say, you can perform computation at the edge, and the edge is this sort of amorphous term to describe having multiple servers distributed across the globe so that the person on their browser or phone who's going to access your site can get it from a data center really close to them. And so that's the edge. The edge, you're just really close to that user and you can do computation like you could do stuff. You don't just serve static pages anymore. So that's a capability in Shopify is working on that with Hydrogen and Oxygen. You have the old-school concept to CDN and that's all baked into the idea of the edge computing. So these are powerful tools that make your ability to handle traffic load future-proof.
Like every client, every possible client on the Solspace client roster has to think about what happens if I get spammed. What happens if I get a DDoS attack all of a sudden? Even the smallest tiniest little client websites suffer from this. So we put them behind something like Cloudflare. So Shopify has had this sort of part of the stack it's built in. And you have this componentized concept of web development in the form of React and Remix, where you can future-proof how you're composing pages for your users to consume on their devices by building on a componentized system where components are shared, and you don't have to rebuild something that somebody else has already built. So you have all these tools coming together to make the idea of gradual web development and progressive improvement of a website so much more easier, so much more easy to do.
David: Definitely. With all of these technologies, you're building websites on the shoulders of a giant.
Mitchell: Yeah. Yeah, that's right. That's true. You don’t have to rebuild stuff anymore. Just use what's there.
David: Exactly. Just reuse.
Mitchell: What do you want to explore next? You did a Shopify exploration. What are you going to get into next? What looks interesting out there?
David: Right now, Mapbox, because I'm working on something really cool for a client. It's been fascinating the way this company managed to integrate maps and how developer-friendly their documentation is. It’s really awesome.
Mitchell: Oh, that's good. I like a competitor to Google whenever I can.
David: Yeah, definitely. I do too. All right, David. Well, thanks again for making time. Thanks for educating me on Shopify headless. And we'll have you on again soon to talk about the next set of tech stack stuff you're exploring.
David: Ok. Thank you, Mitchell.
[Music] You’ve been listening to the Solspace podcast.