Headless WooCommerce with Jacob Arriola

Do the Woo - WooCommerce Podcast, Community and News
Do the Woo - WooCommerce Podcast, Community and News
Headless WooCommerce with Jacob Arriola
/

Headless WooCommerce, you’ve come a long way, baby. And you have a longer journey ahead of you. But seriously…

You may or may not know what headless even means when it comes to WordPress, or even WooCommerce. Or perhaps you are on top of the game. In any case, it’s the one of the pieces of the WordPress future that you will need to have at least the knowledge of what it means.

In the Woo builder community, knowing how a headless, decoupled site blending with Woo is something even the experts are starting to grasp. So there was not doubt on bringing Jacob Arriola from Zeek Interactive come on the show and talk about it. Why? He has been there and done that.

A Chat with Jacob

Jonathan and I chat with Jacob about:

  • How does Jacob Do the Woo and what led him to WordPress
  • When and why did headless come into Jacob’s radar
  • What is headless when it comes to WordPress and WooCommerce
  • What are the positives and the trade offs with the approach to headless with WooCommerce
  • What are the benefits of using a decoupled application
  • How has his experience been with having both a web application and a native application building Rudis.com
  • Why the hybrid approach was taken using WooCommerce
  • What role extensions play in working with decoupled applications
  • What line is drawn when handing a headless site over to a client
  • What is Jacob looking forward to in future of the WooCommerce ecosytem
  • What concerns does Jacob have about the future, WooCommerce and decoupled applications
  • Where should a Woo builder seek out guidance for pursing the direction of headless

Connect with Jacob

Other resources and links

Thanks to Our Pod Friends

WooFunnels



Need to help your clients create optimized sales Funnels using their WooCommerce shop? WooFunnels gives you and your clients all the tools needed to create high-converting funnels using WooCommerce


Check out Nexcess’ new eBook, the Essential Guide to WordPress Plugins to create your own plugin strategy and extend your site’s capabilities purposefully. Download the guide for yourself. 

Jonathan: Welcome to Do The Woo episode 135. I'm your co-host, Jonathan Wold. Bob, are you staying cool?

Bob: I am staying cool. Now we finally got out of on the coast is the dreaded 90 degree which is unusual for this area.

Jonathan: It's a big deal.

Bob: So we're back into the high 60s which most people would say burb but I'm loving it. So I'm happy.

Jonathan: I am trying to do the same. I'm a little bit further east from you and we're having some record highs over here. I'm enjoying central air conditioning right now.

Bob: Cool. That's all that matters.

Jonathan: We have a fantastic guest with us here today. Jacob. Jacob Arriola is joining us. Welcome to the show.

Jacob: Hey, thanks for having me. Glad to be on from sunny Southern California over here. Nice and nice and warm as well.

Bob: You can enjoy our heat from a distance.

Jacob: Yeah, totally.

Jonathan: Excellent. So Jacob, you have a lot of interests, a lot of a lot of things that you'd like to do. We're going to be talking quite a bit about headless and WooCommerce. But before that, I want to hear about your backyard farming. What's the deal? What do you like to what do you like to grow?

Jacob: Yeah, I've always been interested in farming and gardening and urban farming, whatever you want to call it. I started off small with a typical tomatoes and squash and stuff and citrus trees. But these days ever since pandemic last year, kind of tuned that up a lot. So, growing everything that we eat. My wife and I are vegan, so we grow everything we want to eat. Eggplants, corns, berries, citrus, lots of peppers and stuff, chilies, jalapenos and all that stuff. So really, really good stuff. Learning a lot about companion planting, right, plants that go well with one another, help each other out. Yeah. Bringing in the pollinator. So all that good stuff. It's definitely a nice way to get away from the computer and pounding away in the keyboard to be out there in that kind of quasi nature for sure.

Jonathan: What have you found the hardest to grow?

Jacob: Blueberries have been really hard. So it's kind of understanding what zone you're in the country, right? And so finding the right things that are good for your temperature and so it's hard if you don't have the irrigation set up and stuff like that. So especially when we get into peak summer to keep things nice and moist.

Bob: I'm on my way down there right now. I'm going to come out and sit in your land and eat. It sounds good to me.

Jonathan: That's amazing. It's also just amazing what you can do with the space in general. Am I right in inferring that that's one of the perks of being able to work from home is being able to have time?

Jacob: Yeah, totally. Because if you're having to drive commute somewhere, right, you may garden, you may irrigate them in the morning and if you come back 8, 10 hours later, the sun has been hammering in all day whereas if you're home, every time you're taking a break and go out there and kind of adjust the shades, apply water where you need, clip stuff like that. So it's definitely advantageous.

Jonathan: Love it. Well, so before we jump into development topics, one of the things I'm really curious about, so if I understand right, you had a big business background before development.

Jacob: Yeah, totally. So I actually have my MBA. So my specialty was in finance. So in a perfect world I should have been in M&A mergers and acquisitions or private equity or something like that but I graduated from B School, right at 2008 when the economy tanked so all the finance jobs are just gone. But I happened to in school, we took some kind of tech classes and I got really attracted to the development side of things and just started doing it on my own for fun. And it came so much fun that I decided, hey, this would be a pretty good gig, something to do for a living and I just kind of learned on my own just took off from there, for sure.

Jonathan: So I have to ask the question before Bob drops me as co-host. How do you do the Woo?

Jacob: So I work for Zeek Interactive. We are a dev agency. We do a lot of WordPress stuff and WooCommerce stuff. Mainly what we do is a lot of custom WordPress, WooCommerce themes for clients or plugins and stuff like that. And so that's kind of the space that we're in in terms of the WooCommerce side of things is building out custom things for clients specifically in WooCommerce. Maybe some ERP stuff too, but.

Jonathan: Nice. So with that business initial background and this transition to dev, how long have you been in the WordPress/WooCommerce space?

Jacob: I would imagine around seven or eight years from kind of the first time I picked up WordPress to now, give or take. Yeah.

Jonathan: And did you do development in other languages or frameworks et cetera prior to that? What did that path to WordPress look like once you decided to go down the development route?

Jacob: Yeah, I was doing some consulting work for a company.They had a lot of WordPress sites and stuff and so that was my, besides just learning some of the basics of HTML, CSS and JavaScript, that that was my first introduction into somewhat professional programming was WordPress. And so WordPress was my first kind of entry into programming. And so it's kind of been going on from there for sure in terms of development.

Jonathan: When did headless quote unquote first come onto the scene for you? When did you first become aware of it, start experimenting?

Jacob: I remember in a WordCamp2016 maybe. Seeing like some Angular, REST API. Right? That's when Angular was kind of coming into the space and if anybody was wanting to kind of build out themes or something decoupled, it felt like angular was the thing there and I looked at it, I was like, what is that? And then it kind of just went away for a little bit in terms of part of our workloads, we didn't really do anything with it and find any use cases. It wasn't until two years ago, I remember Jason Bahl, just listening to him on another podcast. He's the author and creator maintainer of WPGraphQL. Hearing that kind of brought headless back into kind of play for me and reintroduce the topic in terms of exposing data from WordPress via a GraphQL API.

Jonathan: Okay, so I want to talk about headless for a bit. I think at this point, most folks, if you're building with WooCommerce, it's something that you've come across in one way, shape, or form. And ecommerce is an interesting intersection like application, right? There's some interesting ramifications if you're gonna consider headless. Can you kind of set it up for us, though, for those who have maybe you've heard of it, but let's assume that some don't know much about other than hearing some of the terms. What is headless? What does it encompass? What's it all about?

Jacob: I'll give you the way I understand it. Right? There's a lot of different interpretations, I think maybe so. We take WordPress and WooCommerce as an example that is a monolithic application, meaning it's responsible for a lot of things. It's your CMS, right? Your admins, your shop owners log in and add content, you've got media library, it's got products, it's got orders, et cetera. But it's also responsible for serving the front end, right, the public facing side of your application, right? The product catalog page, the single product page, the cart page, checkout, so on and so forth. So it's doing a lot of things.

And so when you talk about headless, the head really represents that view layer, that UI layer, that public facing layer. And so when we talk about what is headless, we kind of when we cut off the head or we decouple the UI, now WordPress, WooCommerce, is no longer responsible for delivering the front end of the application. It's only responsible for being the CMS, which it's really, really good at, right? And then in the WooCommerce case, all the logic regarding ecommerce variations, orders, all that stuff, database facilitation, payment gateways, things like that.

And so now you are now responsible for building UI in a different kind of context, whether that's a different domain, a whole different framework, whatever the case may be, right? So we separate that out the head, the view layer, the UI, what's publicly available, publicly viewable to-

Jonathan: I think it's unfortunate that headless is becoming a popular term and decoupled is maybe... It just headless evokes such negative imagery. Why would you want to cut off the head?

Bob: Yeah, it does. I think the Legend of Sleepy Hollow. I mean, I just want to interject though, Jacob. That is one of the best explanation so far I've heard of headless. I've listened to a lot of explanations, a lot of people have lost me, which doesn't take a lot for that. But that was really good. In fact, I'm going to pull that out and I'm going to make a poster and put it in my office and that way, I'll be reminded of exactly what headless is according to Jacob. Thank you.

Jacob: I think Matt Mullenweg just started kind of trying to have people discuss it as decoupled, right, instead of headless.

Jonathan: Yeah, it's interesting. I like that idea of thinking about WordPress because there's so many things that you get when you use WordPress, right? You did a post recently where you were describing your approach to headless with WooCommerce and WooCommerce being another example of that, there is so much logic that gets worked out. Okay, talk us through some of the positives and the trade offs, the benefits and trade offs of a decoupled approach.

Jacob: Oh, boy, there's so many, right? It's all use case, but I'll throw out things that can top them back top of mind. The trade offs. One of the things I think that makes WooCommerce have such a low barrier to entries for a lot of builders is the add on kind of space. I mean all the plug ins. You need stripe, you need PayPal, there's a plug in. A lot of times it's an official WooCommerce one that's free, right? You add it on, you're good to go. But beyond that a lot of functionality that starts expanding your shop, like a wish list, right?

So all sudden, if you want to have wish lists on your store meaning if something's out of stock, hey enter your email address, we'll email you when something is in, right? You as a shop owner, the builder, you weren't responsible for building all that logic on the back end for building the form taking in the form, the security behind taking in an email, running cron jobs to ensure that hey, this thing is back and go fire off emails. And so that's kind of one of the things but when you go into headless, these third party add ons have no idea about your headless application. They're assuming that you're in a traditional monolithic, non-headless stay, right? They don't know that you're either using the REST API or the GraphQL API to consume data from WooCommerce to build it in a different framework, right?

Jonathan: They presume that you'd be using a traditional theme.

Jacob: Exactly. So now, depending on the level of complexity, right, you've got the UI layer to rebuild all that but you also have to expose a lot of this data into the API. Now, if you're using something like REST, a lot of plugins now have kind of exposed their stuff into REST but something like GraphQL, it's pretty kind of bleeding edge stuff. So I haven't come across a plugin that's quite yet has a GraphQL kind of layered to their plugin as well for data.

Jonathan: So one of the trade offs it sounds like is if you rely heavily on extensions within the WooCommerce context, you have to check and make sure that those extensions have a support or there's a there's an approach to support for the functionality, otherwise, you're basically gonna have to recreate key aspects of that functionality, if you can use it at all. Maybe let me just start with the positive. I think there's important things to consider on the trade off side of things. And that leads to some of the different potential hybrid approaches that you might take, right? Why would you want to go down this path to begin with> Talk us through some of the benefits of using a decoupled application.

Jacob: Performance, right? Site speed, right? That's one thing that that sticks out. And now within a lot of the lighthouse changes or the SEO algorithm changes that may affect your SEO, how fast Google perceives your site and stuff like that. So because traditionally WordPress in a normal state, in a monolithic state is responsible for everything being the CMS, talking to database and also serving the site. It's in the past, we found that even if we're doing all kinds of optimizations of page caching, object caching, all kinds of things, we still found that there were performance limitations, right, in terms of how fast the site is and feels to the user, right? So one advantage of potentially decoupling it is now you're going to be able to use a different framework, something like GatsbyJS or NextJS, which is built to be fast, right? So you're going to start using a performant framework to deliver the UI and the experience to the user. Right?

So that's one thing in terms of the advantage of going decoupled headless is performance. Another one and projects that we take a look at is UI flexibility. So if your client or your in house, you want to start really kind of breaking apart the kind of off the shelf designs that WooCommerce gives you, especially with a lot of kind of single product pages in the archive pages, the API of WooCommerce with the whole hook system allows you to really start breaking it up, but it's a double edged sword, meaning the more and more you start customizing, the upgrade path becomes more and more difficult, right?

And WooCommerce does a great job of documenting, hey, we've changed this filter, we've updated this template, and you can see, but now you've really kind of stretched out a lot of the PHP templates of customizing the layout, whereas in a headless state, you've got a blank canvas, right? You build out your UI however you want, right? All you're getting you're consuming your data from WooCommerce, right? Now, it's a matter of great, how do you want your single product page to look? Do you want whatever the add to cart on the top left and in a fixed position and all this stuff? So it's easier state that way.

Jonathan: Now, that's also a double edged sword, right? As long as you have the resources available to you, you can do quote unquote, whatever you want. So there's the performance benefit. There's this sort of creative flexibility, which is double edge but in the right setup and context, that's fantastic. You can really build some unique applications and still have that WordPress WooCommerce connection. Are there any other particular benefits that stand out to you?

Jacob: I think in a developer experience, perspective too, right, I'm more of a JavaScript developer than a PHP developer, WordPress developer. So I prefer, especially when I'm doing UIs to use JavaScript. And if we're doing a lot of heavy state management, meaning what attribute has been chosen based on that, do we have a variation, show a modal if we click on this, all kinds of UI state management, if we're looking at a filter on a product catalog page, managing all that state, I prefer something like React rather than dealing with something like... Instead of a WordPress template of jQuery and just kind of a bunch of JavaScript split around. So the developer experience for me is another kind of pro in terms of working in a decoupled state.

Jonathan: One of the other things that stands out to me is the potential for multi application experiences, right? Where you can have a web application, you can also have a native application. And WordPress can still be at the heart of multiple things, right? You can use the APIs. Have you had any experience with that?

Jacob: Yeah, totally. So the product that we recently did Rudis.com, that's a decoupled WooCommerce site application. And the nice thing is, yes, the web app now consumes the data from WordPress, but down the line, we're in the process of building a native app. And so we've kind of already set the stage for the API to be able to provide data to all kinds of other consumers of that, whether that's a full on or maybe just needs products, right? Things like that. So you're kind of setting the stage for WordPress to just be the data store. Right?

Jonathan: Yes. And management. Yep. Yeah. And when you think about, I love thinking about WordPress as an operating system. When you think about it that way, it's like we're opening up, because ultimately when you think about building on the open web, you want to have that flexibility to be able to build experiences for any number of endpoints, if you will, and take advantage of maybe what proprietary platforms can offer by building custom applications for that, yet still having an open source thing at the heart of it that's yours.

And I think that's one of the things that the decoupling movement opens up in terms of opportunities. You can keep WordPress right at the heart and have that flexibility. Like when I started playing with GraphQL for the first time, I remember feeling some of that same magic I felt when I started with WordPress for the first time, where it's like, oh, wow, it just opens up possibilities. So it's like, hey man, I can get that data out this way and it's fast, it's efficient. And wow, that really gives me things that just weren't readily possible before.

Jacob: Yeah, one of the other things too, Jonathan, is about one of the pros and positives is the resources on your WordPress server, WordPress, WooCommerce server, right?

Jonathan: Ah, yes. Okay.

Jacob: Right now, because if you're in a typical off the shelf WordPress site commerce application, your server is obviously responsible for serving visitors and handling traffic and stuff like that and it's also responsible, maybe there's third parties, and maybe you have an ERP inventory system that's hitting your WooCommerce site as well and you've got editors going in there and updating stuff. So there's a lot happening, right? And so if you have spikes of traffic ie Black Friday, right, or marketing emails that are going out Tuesday afternoon for a product launch, the server all of a sudden is going to be responsible for a lot more resources. And so if you're not a DevOps Pro, how much RAM should you be having when just responding to some kind of spikes?

If now you're in a decoupled state, right, something like Gatsby or Next where all those pages are built ahead of time. They're slapped on a CDN somewhere across the globe so if someone's coming from South Korea, they're getting that HTML file from a local data center. And you're really only reaching to WordPress for certain things, maybe the add to cart, maybe an inventory check. Right? But for when someone lands on the homepage, yeah. So when someone lands on the home page or product page, WordPress is not part of the picture, right? It's a CDN. So the likelihood of outages decreases theoretically. And so that's definitely a pro in that regard.

Pod Friends: Hey BobWP here and I’d like to take a moment to thank to of our Pod Friends for their support of Do the Woo.

Need to help your clients create optimized sales Funnels using their WooCommerce shop? WooFunnels gives you and your clients all the tools needed to create high-converting funnels using WooCommerce. And to add to that, their CRM lets you create broadcasts and automated workflows with unlimited contacts. In the end, its not just building the shop, but building sales and a solid customer base. Just visit buildwoofunnels.com to learn more.

As a builder you know the challenges of swimming in the sea of plugins, whether it’s for WordPress or specifically for your WooCommerce shop. Whether you are building sites for clients or simply giving them some direction, the Essential Guide to WordPress plugins from Nexcess is you go-to resource. It will help you or your clients discover the top WordPress plugins, how to vet those plugins and, most importantly, create a plugin strategy. Why not extend your clients sites with a guided hand, and save time with this ebook. Just visit go.nexcess.net/dothewoo to download the guide.

And now let's head back to the show.

Jonathan: As the complexity of applications increases, that's part of what we're talking about here. Right? WordPress, we're doing a lot more with WordPress than we were doing a decade ago certainly. And it opens up that much more possibility because rudess.com I think is actually a great example. It's fast. It's a fairly complex, there's a lot going on there. Maybe talk us through the approach that you ended up taking with that hybrid approach of how you use WooCommerce. Talk us through that.

Jacob: Yeah, so Rudis.com, they're a wrestling apparel, just a sports apparel site. They sell shoes and t-shirts and stuff like that. We've got a hybrid approach in terms of it's a Gatsby application. Gatsby is a React static site framework. Not to get too into the weeds on that. But it's Gatsby in terms of serving the site. In terms of it being a hybrid, right, there are certain times when we're reaching to WooCommerce to do certain things, right? It's not just a static site. There are mostly static assets but there are certain times when we reach out to WooCommerce at runtime, meaning when someone visits the site and need to do something on the fly. For instance, when you select a products attributes, we need to check whether it's in stock, right? And show something to the UI and say, yeah, this is in stock or only one left or out of stock, whatever. That's a request out to WordPress, right, at runtime, right? That's kind of a hybrid approach. And something like add to cart, right? So when someone wants to click that button and add to cart, the request is made out at runtime, right, on the fly out to WordPress and WooCommerce does its thing in terms of sessions and all that stuff and send this back the cart.

But one of the one of the things that we were kind of, not stuck on, but discussing as a group internally in terms of what to do was checkout, right? And I wrote a blog post about this just a couple days ago in terms of how we handle checkout and how I like to handle checkout. With headless, checkout, depending on the complexity of your store, can be really complex, right? That's the final stage in the sales funnel, right? So you can have multiple payment gateways, right? You can have PayPal Standard, Amazon payments and PayPal Pro or whatever the case, right? You have third party plugins hooking into checkout. Maybe you wanted to add someone as a subscriber to your site or.

Jonathan: Yep, you could be using Apple Pay. I guess any number of things. Yeah.

Jacob: It goes on and on, right? So do you want, because you're in a headless state, as a developer, do you want to take that on and have to rebuild all that functionality and support all those things? Not to mention form validation. Form validation is really, really hard, right? Did you enter the right credit card number or you're missing a required, stuff like that, right?

So what we decided was to take on a hybrid approach for checkout is when someone actually clicks on Proceed to Checkout from the cart page, instead of React taking care of that, we send them over to the native WordPress WooCommerce site, right, and we send along the session ID to WordPress and then we have some, and you can look at the blog post, we have some hooks that listen in, whether that's present and loads the correct session and then now you're normal and kind of good to go in terms of all that normal WooCommerce stuff.

Jonathan: I'm curious about it. So in playing with Rudis, it feels seamless, right? You have to be paying a lot of attention to notice the difference. If you think... Zoom forward to the future a couple of years. What's your instinct? Ultimately in terms of performance is it going to be better to have all that stuff sitting in the single application? Or do you see that side of things just getting better where it's like, yeah, this is gonna continue to be the approach. It makes sense today. What's your instinct about a few years from now?

Jacob: I have no idea. I don't know. I mean, it seems like the WooCommerce team, the Automattic team is focused a lot on the block side of things, right? That seems to be the initiative, just kind of looking from afar. And not necessarily headless or exposing the API and things like that. So I don't know. I know for now that's the right decision and I think as developers, we're nimble enough to pivot where we need to. And I think there's just a ton of resources to be able to do that.

Jonathan: Yeah, it's gonna be interesting, because it is complex and one of the things that WooCommerce gives you is that vast ecosystem of extensions and all that that entails, right? So either there ends up being a path where those extensions can readily make themselves best practices standards, they can readily make themselves available to things like GraphQL, or that hybrid continues to be the approach. The blocks gets us closer there in terms of being more JavaScript centric and that flexibility. Or you end up having a lot of that end up being recreated in frameworks like Gatsby. I'm curious to see how that develops. It feels like a middle ground approach is probably the ideal where these frameworks, these extensions become more and more aware of decoupling applications and use cases and anticipate that. What are your thoughts?

Jacob: I think that the developers are kind of going to help drive that kind of through opening up issues to discussions and stuff like that. Asking for more and more of those things even plugins. If developers are going to start asking for things like hey, where's the data in the GraphQL API, right, you're gonna start seeing plug in authors now expose that stuff over to the APIs and stuff like that. But kind of going back to check out too, if you look at other platforms for checkout, usually there's that concept of like a hosted checkout, right? Where if you're paying attention, like you said, Jonathan to the URL and what's really happening, when you click on checkout, that URL is going to be a little different is going to be like secure.checkout/whatever, right? And so it's kind of a known thing. It feels like that's the pattern for that but.

Jonathan: Yeah, it's complex enough of the thing that it's typically like, yeah, we're gonna leave this on its own. And I wonder if it's more like this is what we can do today, my instinct is that is the case. So it's like that's the last frontier in terms of complexity. So we're gonna leave it alone.

Jacob: I think too WordPress as a whole is obviously paying more attention to performance, right? I think recently, to give you a contrived example, just the lazy loading attribute was added to image tags, right? What was that like? Five, six or five, seven, I forget. And so you're seeing those things. WordPress isn't going to move right away and respond to things so quickly, but you're starting to see things like that start trickling in. And so it's not to say that WordPress as a whole as a framework isn't gonna adopt, adapt rather, but I think right now for certain use cases, decoupled is still a great solution especially with a lot of the tools and resources out there to kind of implement these things.

Jonathan: Especially when there's clear paths towards hybrid approaches where it's needed, right? You can have all the benefits of a decoupled approach, mitigate those trade offs by using like checkout hosted by WordPress, and which significantly reduces the draw on your application.

Jacob: Yeah, I think too the responsibility when you're in decoupled headless mode now falls more so on the developer than on the framework, on the UI, on the UI. For instance, right, if you're a normal WooCommerce land, right maybe you're building a theme, but you're not really changing core logic of things like add to cart and variations and attributes and all that stuff and slideshow. Whereas if you're building you your UI from scratch, right, now the burden is on you the developer because you've built that. Yes, you're getting data and you're you're sending mutations over to WooCommerce and it's handling that, but there are bugs that you didn't know that existed that kind of WooCommerce takes care of for you, right. So you lose a lot of that. I'll give you an example.

Recently on Rudis, there was a bug where if you had something in your cart and you just need left, right, and you eventually came back, right, the session is still there. So the next time you load the site, it says, oh, yeah, you've got 10 things, right? But it so happened that one of the products that was in my cart when I put it in my cart was published, but then after the fact when it requested again, was in draft status or something like that or deleted, and so that just like bogged the site. Those are just weird edge cases that if you're normal WooCommerce line, WooCommerce is thought of those things and it's gone through the wringer on those things. And so depending on the size of your team, you may not know about that. You've kind of overlooked that, if you will, right? And taking it for granted. So those are the things to be aware of but if you're using stuff like TypeScript and testing and to end tests and unit tests, you can try to plan as much as you can ahead of that.

And that's the cool thing too for me for a project like that was I had heard a lot of these really cool things out there but I wasn't really in a position to use them based on just kind of use cases and stuff like that. I wasn't able to write TypeScript in a WordPress theme, right? That just wasn't really a thing, right? But in something like Gatsby, I can write TypeScript that helps me not to get on a tangent on TypeScript but that can help me address bugs earlier on than I would have felt just using native JavaScript. I can write a lot of unit tests. I can do a lot of really cool end to end testing, for instance. So that the host we use now five for headless applications and the cool thing they have is every time you have a PR, right, you want to make a change and it runs and you build based on those changes and has a publicly accessible URL and you can send that to the client like here's the changes and you're good to go, right?

And the nice thing is you can tie in your end to end tests with that PR. So once the site is built, based on that new state of changes, you can trigger an end to end test, meaning hey, robot, go through the thing, go to this page, click on this attribute, right? Click add to cart. Go through the whole shopping experience, go to checkout. And does that work? Right? That's just one case. There's all these different assertions that that that I have running and so that makes me feel a lot better in terms of catching bugs, addressing issues, because a lot of these really cool tests, I was able to write that I really couldn't write to the extent.

Jonathan: What percentage of those tests and assertions, if you will, did you have to come up with versus you went to these are some standard ones in this particular type of applications?

Jacob: It was pretty much from scratch. Everything that you're building like um. It's one of those like when do you need to write a test situations, right? Once I start having to repeat something over and over and over after I deploy something, that's usually the sign I need to like write a test for this.

Jonathan: It's interesting because one of the things that we're touching on here is that we don't know what we don't know. And this is a general thing that someone like ah WordPress or WooCommerce. What do you don't realize is just how much has gone into it. And sometimes it's like, oh, I don't want this monolithic application because it's like, well, there's a lot that it's actually doing and there's a tension there, right? Because, yes, you cut it all out, you can get a lot faster. And then say, well, but sometimes then you get into these situations where if you're not asking questions and if you're not really looking and thinking about that experience, you could end up saying, hey, I'm going to make a decision here with the UI, this seems right. We're going to do this instead.

And hey, you might end up introducing new things that are confusing to folks where it's like, well, why did you do that? And even attempting to mimic a certain thing if you don't understand it fully. You mentioned form validation. That's a great example of a thing that you really do not want to recreate if you can avoid it. Because like, oh, that's fine. I'll do some form validation. Like well, really.

Jacob: WooCommerce has been through the wringer, right? There's been so many eyes in terms of UI layer, not even talking about the ecommerce logic. Right? The UI has had so many sets of eyes on it. It goes through so many tests. And so you're right, you take for granted what's involved in that until you start doing it yourself.

Jonathan: All that's to say yes, innovate and take the blank canvas approach where it make sense because that we want to see those things. Just don't throw, just don't disregard, right? So I'm curious. You're talking about some fairly technical things, right? Like dealing with end to end testing, dealing with TypeScript? For someone who is feeling that okay, I'd like to get into this stuff, I'd like to play with decoupling, but maybe they have a more traditional and PHP background. How would you guide someone to start? How would you, in terms of making all this accessible or ramping path if it exists, how would you guide someone to start?

Jacob: That's interesting. So yeah, I definitely consider myself a JavaScript developer so the decoupled UI I would use to build it would be JavaScript, right? So if someone were to ask me, hey, I want to do headless, my first assumption is you're going to do it in JavaScript. But if you want to do it in PHP, if you don't want to learn JavaScript, to that extent to be able to build a full on application in JavaScript, right? Maybe you know enough JavaScript to do a little UI sprinkling here and there, right? Just because we're headless doesn't necessarily mean you have to do it in JavaScript. WooCommerce is exposing that data to you, right? It's up to you how you want to consume it and where you want to consume it.

So maybe you're a PHP developer and your flavor is Laravel. Right? Alright, well, fine. You're just going to consume that in your decoupled layer of application and build out your store that way, right? And maybe you feel comfortable in that stack because you're a PHP developer. So it's important to know that decoupled doesn't necessarily mean you have to be a JavaScript TypeScript developer, right? You could still stay in your flavor. Maybe you're a go developer, I don't know. Or I know there's some people that use like GraphQL inside of WordPress, which is interesting. I haven't explored that.

Jonathan: It is interesting, yeah.

Jacob: Maybe they like that rather than doing like the WP query class. I don't know.

Jonathan: If you haven't learned the WP query class, it can be pretty intimidating. It is interesting though to see GraphQL in pin context will be.

Jacob: If someone is definitely still looking into going into like the JavaScript side of things, I think the WPGraphQL Slack community is a great community. You go through the WPGraphQL site and I think there's like a link on. There's where you're going asking questions. Jason Bahl and the maintainers are really good about answering questions and getting people started. And so I think those are great resources for sure.

Jonathan: WPGraphQL is a great example of an ecosystem that's right in the middle, that's at the intersection of obviously, WordPress, the PHP application and GraphQL which is predominantly JavaScript and in terms of how it's used. Yeah, that's fantastic. And, Bob, you did an episode with Jeff Taylor, who's the maintainer of the WPGraphQL extension. It wasn't too long ago.

Bob: Yeah, yeah. That was a little while ago.

Jonathan: Maybe we can drop a link in the notes.

Bob: Yeah, I'll make sure to do that and also, if you want to listen to it, we'll put that link in as well.

So I do have one more question before we go and with all that's been said, going back to that developer that just starting into headless and looking at it and maybe dabbling in it, they have a client come to them. And this one client says, hey, I want headless. Maybe they, I don't know, maybe you told them to tell him that. Whatever the case, however they made that decision, yeah, we're gonna have you help us along the way, we're getting this all figured out.

But then you have another client that says they want that and say, we want headless, or some hybrid, they think they understand it. And they say but then we want you to hand the whole thing to us. We're going to take and run with it. We like to get in there. Our developers like to get in there and do stuff. Does that approach making a difference you knowing whether they are going to be more hands off or they're going to be more hands on with what you've done with their site?

Jacob: Headless doesn't change the game in terms of you've built something, it's sitting in some kind of repository and now the client wants to take over and write code, because it's still code. The game doesn't change in that regard. Right? What may change in terms of expectations. Well, I mean, there's a lot that's gonna change but one thing that's going to change that is important to think about is I think WordPress or WooCommerce wasn't built to be headless, right? So it doesn't have that in design.

So you're not always fighting the the framework, but you're trying to find ways and swim through like trying to figure things out. Like the handing off checkout to WordPress, right, that isn't a button that you press and say turn on hosted Checkout for me. You've got to figure that out and solve that problem. And so that's the important thing to keep in mind in terms of now if we're talking to clients is, it wasn't built with that in mind so there's a lot of things that we need to do to kind of address certain situations to make it work.

Jonathan: Extensions are another good example of that, where they're like, oh, well, you can't just install an extension for this application. It's not going to just work out of the box in most cases.

Jacob: Things like previews too, right? If your authentication preview is like how are you handling auth, right? Are you doing a JSON web token? Are you trying to do cookie auth? Right? And so, in WordPress WooCommerce, an auth just works, right? We don't think about that. You add users and the last thing WordPress, WooCommerce developers are thinking about is what's my auth strategy going to be? Whereas now you have to, if you're decoupled, you have to start thinking about, okay, what is my auth strategy and how am I going to do it? Yes, there are resources out there. There's a JSON web token GraphQL option. You can do? What's the WordPress application passwords, right?

But now, there are decisions that need to be made, right, and reasons why you're making the decisions. And so that's the important thing to understand is WordPress, WooCommerce wasn't made with that intention in mind. And so there's some thought that needs to be made behind it. And that's okay. There's nothing wrong with that. But as long as you're walking in and you manage those expectations with developers and with clients.

Jonathan: Excellent. As we move towards wrapping up, we've got a couple more questions for you. So within the context of WooCommerce itself, what are some of the things that you're looking forward to about WooCommerce and perhaps the ecosystem as a whole?

Jacob: I think just hosted checkout, for sure. I'm curious about blocks, right? Like right now, if I'm doing headless blocks to me and headless are just, they're really hard. And you're you're dealing with just a whole nother set of issues. So I'm curious, is it the store API that's kind of in development? I forget what the API is. That's the API that WooCommerce blocks are using to build out blocks, right? It's a publicly accessible one, but it's like pre pre pre pre release kind of thing and it's gonna break. But it's a API that has things like cart and stuff like that. So I'm curious as to how that API is going to evolve and whether they're going to keep it public and how I can hug into it for kind of WooCommerce shops for sure.

Jonathan: And in considering the future of WooCommerce and it was particularly within this context of decoupled applications, are there any thing you're concerned about?

Jacob: I'm concerned about so like the WPGraphQL plugin writes, it's Jeff. It's an open source but it's Jeff who's the one that's kind of creating and he created and maintained it. So support and resources behind his efforts are important via sponsorships and things like that, so that he can give it the attention that it needs, because he's got a full time job and so this isn't his thing. The community tries to contribute but there's a lot involved. Obviously, it's ecommerce and so that's one thing that kind of stands out to me, if anybody's listening to this, is go to that WuGraphQL and offer support, whether that's PR or whether that's monetary support as well.

Jonathan: Any any final thoughts in terms of guidance for builders who are interested in headless? I think looking at examples is a great place to start. Anything else that that you'd offer in terms of giving them inspiration or helping them take action?

Jacob: I think once you get into that selection, you'll start getting access to a bunch of starter templates and stuff like that. And once you do that, start building things and sharing them with everybody and writing blog posts about it because the more and more developers do that, the more we're going to learn from one another and start driving that conversation to really start evolving this thing even more.

Jonathan: Love that. And your blog is a great example of that just in general. I think I'm glad you brought that up for so many of us. writing about your experiences, even as you're working it out, right? It doesn't have to be that you've figured it out. It's like, hey, here's my current state. This is as far as I got. That's just a powerful way to get your thoughts out there to contribute to the broader work that's happening. And I found, at least for me, personally, I'm sure you found the same that that process of writing and knowing that you're going to do that often helps clarify things as you're going.

Jacob: Oh, totally. It's important. I forgot who I met, kind of one of my mentors early on. I saw the problem and his first response was, did you write about it? Did you read blog post about it, right? Just put it out there. It's going to help you but it's also going to help other people and then you're going to be able to connect other people and so on and so forth.

Jonathan: Jacob, if folks are interested in learning more about you, following what you're doing, where should they go?

Jacob: Twitter is the best place, JacobArriola and then from there, we can chat and all that stuff. I try to, like we said, post as much as I can in terms of my blog and things that I'm working on so Twitter for sure.

Jonathan: Excellent. Bob, back to you.

Bob: All I'm gonna say is oh my God. Not kidding, Jacob, you can now put on your resume, I helped Bob understand headless and people will think oh my, if he can do that, then he can do anything.

Jacob: Don't sell yourself short Bob. I'll take it as a compliment though.

Bob: No, this was an excellent, incredible conversation. I know I let Jonathan run with it. And of lot of good stuff. So we know where to connect with you.

I'd just like to thank our pod friends WooFunnels and Nexus for their continued support. You can find buildwoofunnels.com and Nexcess.net. Love my pod friends, love all my friends, love having great guests like you on it.

Again, thank you for coming to this show.