A community of agencies, freelancers, developers and designers building stores, products and services for WooCommerce.

WooGraphQL, Headless and APIs with Geoff Taylor

WooGraphQL, Headless and APIs with Geoff Taylor
WooCommerce

 
Play/Pause Episode
00:00 / 00:42:49
Rewind 30 Seconds
1X

Thanks to our community sponsors

PayPal
WooCommerce

When we have a developer on the show who is passionate about what they do, well, we always end up taking a deep dive into the topic. This was the case when we invited Geoff Taylor, from XWP and developer of WooGraphQL. Mendel runs with it this time and there is a lot of info jammed into this episode.

A Chat with Greg

In episode 80, Mendel and I talk with Greg about:

  • How he became interested in server-side data and APIs
  • When he used his experience to take his work and use GraphQL with WordPress
  • What it means when people say “headless”
  • How it compares to using hooks, filters and endpoints
  • The real power behind GraphQL
  • Using GraphQL and why even still use WordPress
  • Multiple ways to do your WordPress front-end with GraphQL and API
  • How the GraphQL and the REST of API works
  • Whether performance and data retrieval are more performant using GraphQL than it is when using standard WordPress through a theme
  • Using WooGraphQL vs the WooCommerce REST
  • What the future holds for GraphQL

If you are a developer wanting to learn about or dig deeper into GraphQL and WooCommerce, this is a must-listen show. Greg really knows his stuff.

Connect with Greg


PayPal
Download the PayPal extension on the WooCommerce marketplace to offer buy now, pay later options.

WooCommerce
Start your next career in WooCommerce at WooCommerce.

The Conversation

Bob: Hey, everybody. BobWP, and we are back with Do the Woo episode 80. 8-0. And of course, I have one of my co-hosts, one of my favorite co-hosts. In fact, all three of them are favorite. But hey, Mendel Kurland, how you doing?

Mendel: Hey, what's up? Hey, Bob, it's okay, I know it's public, so you have to say that you have three favorites, but I know where you stand. I know where you stand. And it's cool. It's cool. I'm sure they know too, deep down inside.

It's good to be here. I'm excited about this conversation. It's going to get nerdy. It's going to get geeky. And I feel good about that. I feel really good about that.

Bob: Yeah, Mendel, you certainly will be in your element. So let's go ahead and move on into the show here. But before I do that I want to thank our great sponsors.

First of all, PayPal. As I've been talking about since they became a sponsor, their Pay in 4. It's a pretty sweet way that your clients, customers, make purchases on their sites between $30 and $600, and they get four interest-free payments. That really is nice, because talking to them, they fit it every other week. So it fits the model of the person that gets paid every two weeks or twice a month.

Mendel: Bob, I want to double your shout-out for PayPal, because I installed the new PayPal plugin on my website, and I enabled the Pay in 4. I didn't even have to enable it. It just came out-of-the-box, it was enabled. And it's incredible. It automatically takes the cart total and allows you to allow somebody to pay in four payments and it's interest free. It took me five minutes to implement. So just go do it. The holidays are coming up. Might as well.

Bob: Yeah, no doubt. If Mendel did it then ...

Mendel: That's right, anybody can do it. If I can do it, anybody can do it.

Bob: That's it.

Then there's WooCommerce.com. Let's see, 4.7 RC came out the last week. So just want to remind everybody get that testing wrapped up for the release of the 10th. Very, very minor updates, because they did not want to break your site before these holidays. So you can be rest-assured that everything will go very smoothly. Well, as Mendel said, we have a great guest today, Geoff Taylor. Geoff, how are you doing?

Geoff: I'm good. Yourself?

How Geoff does the Woo

Bob: Doing really good. And like Mendel said, we're going to get geeky, and I think the best way to do that is figure out what the heck you do with Woo. What do you do with WooCommerce?

Geoff: Well, right now I work primarily as a consultant and just work for a specialist, XWP, and I also am the developer of WooGraphQL, which is the GraphQL's API functionality for WooCommerce. I'm typically a consultant/developer as far as on a couple of different WooCommerce projects that are coming up and being released and have been released. I specialize primarily though in just data management on the server. So improving the request speed and performance for service side requests when it comes to data management for headless applications.

Bob: Cool. Wow, that's a mouthful. That is some serious stuff.

Geoff: Well, it's just a really fancy way of saying I make stuff go really quickly. I make stuff faster.

The interest in server-side data and API’s

Mendel: So I want to start at the beginning of your API journey though, because we're talking GraphQL, right? And now we're talking APIs. And there may be some people listening to the Do the Woo Podcast that have no idea what GraphQL is, that WordPress even has an API by itself, right? That WordPress didn't used to have a native API, and now it does, but then GraphQL augments that, and what GraphQL is versus the native API, right? But before we get into that, because we're going to need your help with that, before we get into that let's back up, and how did you even get interested in data, or in server-side data, or in APIs?

Geoff: Well, initially I started as, I guess that you could say I was a freelance web developer, and at the time I worked primarily on the LAMP staff using PHP, then whatever CMS would work for what I needed at the time. Then one time, I had a need for WordPress at the time, I was trying to make a front-end JavaScript application, which is now known as headless in the community, which is typically where you take a WordPress back-end and let that provide the data on the front-end. But I needed something other than REST. At the time I hadn't even really looked into REST.

I actually came across the plugin WordPress-GraphQL before I even looked into using REST. And the beauty of that was it was still a growing project. It looked far less scary than it does now, and I was easily able to get on and just start using it and contributing. Then through contributing I met and got in touch with Jason Bahl, the developer, and it just snowballed from there with me working on several different plugins and uses for it, taking and using it in several applications, because it turned out to be really versatile. I had already had experience and known about GraphQL at the time, but I hadn't been using it in WordPress.

Mendel: Got it.

GraphQL and WordPress

Geoff: When I went to Jason Bahl's project and I started using that, I found that now only was this extremely convenient, it made setup really easy for creating a new application. I just had to install WordPress and then install this plugin. Then from there my journey was all JavaScript, which is typically if you are a theme developer of any kind or something like that, you prefer just to only have to worry about the visuals. And this really gave me that opportunity. Funny thing is though, as I got into developing more of the API I found I had less time to develop front-ends.

So initially, I was a full stack developer, but my focus had never really always been back-end logic. It had become that in developing this, and it turned out I'm really good at it. So I stuck with it, and it wasn't even that I had a personal need for WooCommerce at that time. What brought me to making the WooCommerce functionality was, I had finished up all my projects, I was still working sort of as a consultant at the time, but not for WooCommerce yet. Just for GraphQL and WordPress, the combination of that. But there was a demand growing for two things, ACF support to the GraphQL API. ACF is a humongous plugin in the WordPress community.

Mendel: Advanced Custom Fields for those folks that don't know.

Geoff: Yes, my bad. Advanced Custom Fields. And WooCommerce. Jason had already actually started developing the Advanced Custom Fields extension and was already about to start selling it as a premium plugin. Then I started developing the WooCommerce plugin, because there was a demand for it, and I also wanted to build up my reputation that I did not have in the community. I was a nobody. I was trying to get better remote work, because at the time I was working off of place like Upwork, or Freelancing.com, which I could find work, but the quality of the work and the pay, it was really not making ends meet.

So as I started to build out the WooCommerce API, I built connections. People started coming up and using it. I got consultant work through it, and it not only improved my ability with building WooCommerce extensions, it improved my ability with WordPress development. It improved my ability all across the board on every part of the spectrum, because I made sure I was testing and implementing and making sure it worked from all facets. And here I am now, like a year later. I only started it back in March 2019 and it's become what it is now.

Mendel: Cool. Yeah, that's awesome. It's awesome to hear how you got into it and how you got excited about it, and then how you started to get work from it, which I think is something a lot of people don't recognize. That becoming an expert in any field means that you've done enough in that field, you have a large enough body of work that's been successful that people start to notice and that you can use as your own self-reference.

I think a lot of people maybe sell short their personal experience, or their small business experience, or their freelancer or entrepreneurial experience. And there's real value in that. So I think that's a cool takeaway from that story.

I want to talk with you a little bit about why somebody would use an API to begin with, or GraphQL to begin with, with WordPress. So WordPress, for a lot of people you install on a server, you go into the back-end, you manipulate some data, right? And essentially the back-end is just a UI for a database that does some super complex queries and joins and all this stuff, and then you save those states, right?

Geoff: Yeah.

Mendel: With a whole bunch of data. Then on the front-end you have users interact with the website, right? And they might manipulate data in a database. So that's like a front-end interface for a database. So you can do a lot with WordPress. You can do a lot with WooCommerce. You can theme it. You can make it perform, even with the application. So what is this headless thing and why would somebody be interested in it?

What is this headless thing you talk about

Geoff: All right. When you think about just a WordPress front-end you come up with, I guess now, the modern day of three scenarios. You have a WordPress theme. You still have that same WordPress data, it's just showcased through a WordPress theme. And there're pros and cons to this. The pros are the WordPress theme tends to be the code for that, tends to be bundled with WordPress installation. You have everything together. It tends to be neat and seamless.

But the con to this the data's baked into the layout, there's very little room for customization without making it really unwieldy, and any form of realtime JavaScript application implementation is made that much harder and complex. So if you want to go to something modern, scratch that. You want to do something really impressive or really unique, scratch that. You'd have to gut the whole theme altogether, making it pointless.

Hooks, filters and endpoints

Mendel: I want to break in right there on that point and just say, I think a good example of this is like using hooks and filters and things like that to add things into the output of the site.

Geoff: Oh, not even just that. Think about it from this endpoint. Say you want to make a menu that performs a little bit differently and you want to style it in a way where you don't have to use the complex PHP walkers. You just have the menu items, the menu locations, and you just want to split that out. Doing that through the WordPress theme is made that much more complex, because all of that is tied into the WordPress code.

I don't even want to say it's made impossible, it's made just not user-friendly all through it. If you have to come in and learn a bunch of stuff, that if we're not completely sure it won't be depreciated years from now, a lot of it is just built-in baked-in WordPress functionality that's only used specifically for this menu part. It's just a con all around when you look at it in comparison to the other alternatives.

Then the other way is using WordPress REST and a JavaScript application just to retrieve that data. This allows you to have greater versatility, but it opens your site up to, for one, people have access to the data through another endpoint unless you lock it off. You may have to build a bit more in the way of structure on specific points. You lose a lot of that WordPress built-in functionality, but you get the capability of truly doing whatever the heck you want. But the downside to this is REST does not allow for a lot of versatility in the size and shape of the request. So you'll be limited to what data you get back and where, and those requests can get big and you might not always need the data for every little bit, every little part of the application where you'll be making those requests.

What GraphQL really does

Mendel: And it sounds like that's where GraphQL comes to the rescue.

Geoff: There you go. And GraphQL, it works similar to REST. You'll be able to make whatever you want, retrieve all this data. However, you can fine-tune the request to only grab what you need off those data objects, cherry pick only the fields that you need at that time.

And a lot of the tools on the JavaScript front-end allow you take advantage of things such as caching, no retrieving of data you already have, keeping track of state as well as also manipulating said data within the confines of your application just to modify right here and keep to yourself only for what you need. There's just so many advantages of being able to control the request size and request data to such a fine-tuned point that you easily notice the different in an app that is using GraphQL over using REST.

Thanks to our sponsor PayPal. In time for the holiday season PayPal has launched a new pay later option called Pay in 4. This mean that your clients can offer their customers the option to purchase over time in 4 interest-free payment. This feature is one of two option from PayPal for pay later with the other being PayPal Credit which gives store customers more purchasing power through flexible and transparent choices in how and when they pay. This second option is subject to consumer credit approval.

So offering those payment options is good business. Did you know that 64% of consumers surveyed say they are more likely to make a purchase at a retailer that offers interest-free payment options. And 56% of consumers that responded agree that they prefer to pay a purchase back in installments rather than use a credit card.

Well, this seems like a no-brainer to me. Clients can grow their sales and get paid up front with no additional risk or cost.

All you need to do is download the PayPal Checkout extension on the Marketplace at WooCommerce.com. Just head on over, click marketplace and search for the PayPal Checkout. Suggesting that to your clients will certainly open up sales opportunities for them.

Thanks for PayPal for being a community sponsor at Do the Woo. And now back the conversation.

Mendel: Now, when we're talking about headless and we're talking about using GraphQL, just for, again, the benefit of the listeners, we're talking about creating apps, we're talking mobile phone apps.

Geoff: The beauty to all of this is you can access REST or GraphQL from any device you can make a HTTP request from. This can be a phone. This can be a game app. This can be a game console.

Mendel: Apple TV. Whatever.

Geoff: Apple TV. Anything. You can make an app that will be supported from a WordPress site back-end using Wordpress-GraphQL, using GraphQL or REST. That point doesn't really matter. You'll just get a performance boost that is incomparable from using GraphQL.

If GraphQL can do all that, why even use WordPress?

Mendel: Now, I want to take it a step further, and we're going to tread into uncomfortable territory here, because I'm going to ask you, and I want your honest opinion on this one. Although you don't seem like a guy that would not give your honest opinion. I want to know why even use WordPress at that point then? Why not just roll your own, right?

Geoff: Because I've done this before. Allow me to explain to you the problem of rolling your own versus using an already built community maintained application. Yeah, WordPress may seem unwieldy and different from, it might not even look like it's the top of the line, but WordPress is a Swiss Army Knife. If you need to get through the forest to do what you need to do, WordPress will get you there. You think about it, WordPress at its core is just a basic blogging site. All the plugins come in and add features and functionality that WordPress allows for, and you can create objects to shape whatever you want.

The reason you would use WordPress is, if you go and try and make an API just from scratch you lose the validation at WordPress, you lose the possibility of the functionality that the plugins provide, because one of the things that WP-GraphQL and Woo-GraphQL and a lot of the plugins we've built, is we've tried to make it to work with as many plugins that simply want to add data to the scheme or manipulate the scheme. We've made it work with as many plugins as possible. Like right now we a plugin that works with CPTUI. So when you want to make custom post type, there's another extension you can use that will add those plugins, create it through CPTUI to the GraphQL APS scheme. Same thing with WP Tax and Meta Tax query. You can do complex queries for Tax Meta through the GraphQL API.

We've made plugins that add specific features that would make it so even the reason you would use it is because all the support that WordPress provides out-of-the-box and respective in that same way, the support that both the REST API as well as the GraphQL API use will provide out-of-the-box. Your argument can be that this might be a bit much, or why even use it if you got to alter it this much?

But look at the alternatives, because when you think about it, the setup for a WordPress back-end is as simple as installation, install a plugin, walk away. You have your back-end set up. If that is considered to be a bit much, at that point what is the point? Because typically if you were going to build a WordPress application or a WordPress site the traditional way, you'd do the same thing. You'd install, plugins, modify your themes. This almost no different, except that the process that you are doing to create the front-end just is different than creating a theme. It's really almost no different than modifying a WordPress website. You just need to do things a little differently at specific points.

Bob:I'm not a developer, but I did design and build WordPress sites for many years, and even thinking back on the site I just redid, and how you just explained it to me, it's like, "Okay, I've got the knowledge and the power to build it up to a certain point, but till I need or have a requirement of a certain functionality that I don't want any more or any less and I want it to be quick, then that'd be the time I'd have somebody come in and take care of it using GraphQL.

More on headless

Geoff: Yeah, and to go back to your point too, the beauty of headless WordPress that it gives the capability of doing, you can start from design first, something you can't do through the traditional method. You can design your whole site the way you want it and then build it in HTML, and then bring in WordPress to back that front-end that you have created. That is something that you traditionally can't do with the WordPress application.

And something that I was actually recently able to do recently and realize the side-by-side difference in being able to start from design first, not worry about WordPress at all until afterwards, and then go create it, as opposed to having to shape your design to what WordPress's base theme printouts are. That's something that you really can't do otherwise.

Mendel: Yeah, that makes a lot of sense. So I'm sitting here, I've written APIs, I've played with APIs, I've built sites using APIs, and one of the things that comes to mind when I think of WordPress is getting my head around all this fits together, right? So let's say you're building a website. I'm sure you've built a website with something with GraphQL. We don't need to get more complex than that. So what does the architecture look like when you're setting something like this up? And I'm talking like directory level. You have a WordPress installation. Your WordPress installation comes with a front-end, right?

Geoff: Yeah.

How to set it up so that you can consume GraphQL API coming from WordPress or WooCommerce

Mendel: So how are you setting all of this up so that you can consume the GraphQL API coming from the WordPress or WooCommerce site?

Geoff: Well, there's a multitude of ways you can do your WordPress front-end, and there's been several ways that are being implemented right now. As I'm sure you've heard of Gatsby. One of the big ways that a lot of Gatsby sites are doing because the speeds you get from the static site build is they will set their front-end up at a specific domain using LFI and then they will use Gatsby to build the site by querying for all of those pages and everything in their application to create those pages with the Gatsby code. That's one way of doing it. Then another way is, because you're not necessarily locked to the WordPress front-end, your domain, wherever you point it, that's your front-end, regardless of where WordPress is at.

Mendel: We're putting the WordPress installation and all of the data maybe on a different server, a different domain, something like that, and we're just querying back and forth.

How the GraphQL API and the REST API works

Geoff: Let me explain really quickly how the GraphQL API and the REST API works. When the REST API's activated, or the GraphQL API's activated, they provide an end-point where wherever your WordPress site is hosted, slash, in the case of WordPress, WP, I think dash version two right now, JSON for whatever thing you want to grab, or in the case of GraphQL, Slash GraphQL, and then you send your request through either a POST request or a GIT request, which are variables, and you get back a response in the form of a JSON.

You can make that request both service side and client side and it will respond to it. The beauty of being able to remake service side is the fact you can get SSR support for your applications, and then one of the advantages is you get to use Helmet, and you can combine Helmet and Yoast to spit out your research as SEO metadata. It's wonderful. That's a common thing that people have been doing recently with Next.

If you're familiar with Next.js. They've been building static site front-ends using Helmet to process the header meta provided by Yoast in the header and using that for SEO coverage. Another way that you can do it, though the only person I've known that's actually done it is me, is you can actually use the PHP-V8 extension to process your JavaScript, and within a GraphQL, because you can shove your JavaScript application, your headless application, in a WordPress theme.

That is actually the way I like to do it in all honesty, because I like the self-containment of WordPress, but you wouldn't be able to get SSR support. It's a JavaScript application. To get SSR support you could use the PHP-V8 engine to process the React beforehand and create an SSR spit out on the initial build in the service side request. And that can work perfectly fine.

There are a number of ways you can create a headless application, both self-contained and it's broken out into different parts where you're front-end's at one point and your back-end's at another. Another thing is, if you change in the WordPress settings the current site address, whenever you try to navigate the site address it'll redirect you to wherever you put that at. You can put that on your front-end application, and then from that point anytime somebody tries to navigate to your back-end it'll redirect them to that front-end application, unless they send a post request to your GraphQL back-end, which will still be recognized.

Mendel: That's pretty interesting. That's a fun little trick actually. I like that.

Geoff: Don't do it during development, it will mess things up a little bit and you won't be able to make it up. But it will still react to POST requests and to GraphQL. So your front-end application can still send those requests. Another thing that you can do also is preview support. If you're using the classic editor currently Gutenberg will not let you do it. You can if you're editing a POST preview it in your front-end application with a few minor tweaks to filters and changes and stuff like that. It is very much possible.

We've been trying to implement that and Jason's been adding more support for the draft posts that are created through the editor to help you display previous support. But headless, there's not too much you have to do extra in the way of the basic installation of your WordPress site, it's just how you set up your front-end.

Separating data logic and display

Mendel: And this goes to the whole idea of separating data code and display, right?

Geoff: Yes.

Mendel: Or sorry, data logic and display. And I think it's an important paradigm to look at, I think as you build more complex functionality and as you create more performance sites, because troubleshooting performance is really difficult when you're ... I'd be lying if I said I wasn't guilty of putting output in PHP, outputting it using PHP.

Geoff: Oh no, I can tell you all the little tricks. There's var dump, WPS in JSON. There is absolutely nothing wrong with dumping stuff that way when you want to debug. In my opinion, use whatever tool necessary to dump when it comes to debugging. And in development with a lot of these APIs, I try to help with that also, helping people debug their solutions, because I'm a big believer in testing.

I am a humongous believer in testing, because I hate having to go back and fix things. Everybody does. Even if you want to complain that you're doing it for a client, it'll get you more money, I care about my time. So when you want to make customizations to certain stuff and stuff like that, there are multiple ways you can debug your issues and troubleshoot when it comes to all the GraphQL extensions.

Thanks to our sponsor WooCommerce You may be just starting your journey as a Woo Builder or well into your journey. Or perhaps you have WooCommerce talents that you want to bring to a team as you look to make a switch in your career.

WooCommerce has several roles open that will likely fit your own goals of growth. You will be joining the larger Automattic team, a diverse and distributed group of individuals with a passion for WordPress, and yes, WooCommerce.

If you want are looking for make that career pivot and love working from home, check out all their open positions over on our Job Listing at DotheWoo.io.

Trust me. I know the company and a lot of the people. It's a smart move.

Thanks to WooCommerce.com and their support as a community sponsor. Now let's head back to the show.

Performance and themes

Mendel: So I want to touch on performance, and then I want to give things back to Bob, because he's let me take over a little bit today. But I'm curious to know, forget the fact that you can make a more performant theme, okay? I'm talking about data retrieval. So is data retrieval more performant using GraphQL than it is using standard WordPress through a theme?

Geoff: Through a theme? I'm going to say yes and no. It depends on the page specifically. That's why I'm going to say yes and no. It depends on the page being queried. WordPress-GraphQL is designed to cache specific requests and only query specific things when necessary, and resolve and N+1 problems where you would be querying individual things over and over again. WordPress-GraphQL goes through that, but the base design of a WordPress theme in those queries aren't polluting.

Unlike REST where you will get data you might not need, that's pretty much never the case with the WordPress theme. They only are going to provide the data in the query that you need. Now, if you are doing a custom theme where you might create an extra loop in your theme, yeah, we're going to shit on you in performance when it comes to GraphQL. You're doing an extra query for no reason. Yeah, we're kill you in performance in that way.

When you think about the traditional method, if you were to go and get the 2020 WordPress theme, we're not going to beat that in performance in GraphQL. Probably not. Unless, but here's the thing you also got to think about, there're images being loaded. It depends on the request itself. Matching that request, we could probably match the speed, we can probably beat the page on loading when it comes to the request, especially if it's something where you have SSR support. But out-of-the-box it's just going to match if you just have the 2020 theme or something like that. But a custom theme where there tends to be extra things added to your layout and your appearance and extra cores for different types of data, or if you might bring in ACF fields, your speed, there will be variations, and I'm almost positive GraphQL will beat you on that front.

Mendel: And it is interesting you can bring in component pieces of data as you're painting the page. So you don't necessarily need to bring in a huge payload all at once, because you have the ability to cherry pick the data, right?

WooGraphQL versus using WooCommerce REST

Geoff: Not to toot my own horn, but using the WooGraphQL versus using WooCommerce REST, no matter what you are doing, WooGraphQL will beat it in speed. The basic product query grabs every piece of data on the product object every time. And there is a lot of information on those product objects. We're talking names, prices, sale prices, sale dates, things like that. You're not going to need that if all you want to do is showcase possibly the image, picture, sale price or price. You're going to need maybe 10 variables or 10 pieces of data related to the product, not all like 50 fields.

So when you put it into perspective and look at what you're building performance-wise, GraphQL is always going to win. Performance-wise you're never going to grab anything that you don't need, so you're always going to win. WooCommerce Rest, you don't have a choice. You're going to get whatever the endpoint can provide you, and you're going to have to filter through that.

One thing I've noticed is that with GraphQL we make multiple requests. We make a request at every component that we need the specific data for, instead of making one giant request and then building all the components from that data. Now, if you're looking at this from the React front-end, that means that somewhere you have another place where they're catching the data and sending it, and are forced to send it to whatever component needs it.

While on the flip coin with the GraphQL, you're going to do requests and only get the data that you want at the level of that component. Cleaning up your code as well as cleaning up your performance. I believe a few years back it said that it was better to make multiple small requests than one large one, that somebody said that. And that's still true, as far as I know. Like no one came out and refuted that.

Mendel: Well, you can probably also add a higher level of concurrency then too, right?

Geoff: Yeah.

Mendel: So you can be pulling price and you can be pulling description, and you can be pulling name all at the same time.

Geoff: And one thing is GraphQL, and sequentially WooGraphQL, support batching. So batch requests and stuff like that, it's supported. It'll just take all those requests and run those on the spot and send them back as an array of JSON data that whatever thing you're using that sent out the batch request will process.

Mendel: Got it.

Geoff: So batching and stuff like that to speed up on the front-end is also supported.

Bob: I find it fascinating, because I'm actually starting to learn more and more with our guests on here, and definitely I think this is something to keep on top of you think, Mendel? You think we should?

Mendel: Yeah, it's the future. I don't think it's something to keep on top of, I think it's something that is going to be imperative to know in the next five, 10 years of building sites as people demand faster sites, more complex sites.

The future of GraphQL

Geoff: Yeah. I won't deny that I've seen some kinks that still need to be worked out in the process. Like with the Gatsby build a lot of people have been having issues, especially specifically with clients I've had where they have a lot of content. And every time you make a save to Set-Content it'll trigger a new build. So while all these features I will say are the future, the kinks in their use are still being worked out. So I don't believe there is a super hurry. And like I said, there's so much versatility in how you can make your front-end that I feel like a lot of people are still going to be, just for a long time, trying to work out what's the perfect way to create a front-end.

I spoke to a client yesterday who told me with almost a single button click they can create a new store, and they can vastly change the appearance by just tweaking a styling theme sheet with variables of their CSS styling. There's been so many different ways to tackle the front-end, and it gives you so many options that I don't think ... That while I do agree with you, this is the future, I think there's no rush to learn it right away. There's going to be so much growing in this space that nothing is going to be finite in the way that it's laid out right now.

Bob: Cool.

Mendel: Makes sense.

Bob: Well, I think that's a good way to wrap things up. Mendel, what do you think?

Mendel: Yeah. I've really enjoyed talking APIs and GraphQL and enjoyed talking to Geoff even more.

Geoff: Oh, thank you, sir.

Mendel: And I guess with that, I might as well just help us close out the show.

Before I do that I just want to mention that WooCommerce, it's awesome and also happens to be a sponsor of this podcast. So if you haven't joined the WooCommerce Slack, I know I mentioned it a couple weeks ago, there's a channel for anything, any question that you might have about WooCommerce. Now, pro-tip, don't post the same question in every single channel on the WooCommerce Slack. But if you have a question go and look through the channels and figure where it fits and ask that question, because there are a lot of helpful people there that are interested in helping you figure out the answers.

Geoff: And avoid using the channel tag and the header tag.

Mendel: That's right.

And the second thing I would say is if you have the PayPal plugin installed on your website and you installed that maybe a year ago or two years ago and you've been updating it like a pro, remove it and put the new PayPal plugin on your website. The one that you can download, surprisingly, at WooCommerce on the WooCommerce website. And use that plugin, because when you enable it, first of all, it's way easier to connect than the old way, but the second thing is you can use this for Pay in 4, which is really cool, especially as the holidays are coming up and people are going to want to buy things for their loved ones and maybe they don't have all the cash on hand right now, but they will in the next month or something like that.

It allows people to pay in four payments, which is just pretty cool. And there's no risk to you. Super easy to set up. And they're a sponsor, by the way. I forgot to mention that. They sponsor this podcast. I don't want to leave that out. So thank you to PayPal and WooCommerce. I'm done gushing all over them.

Where to find Greg

Tell us, Geoff, where can people connect with you if they want to say, "Hey", or they have a question?

Geoff: Twitter I guess, @kidunot89.com. Though I rarely talk. I'm more of a listener, and I respond to questions. You will find me all over GitHub, all over Repos making commits and reviews and whatnot, again, at that same name, @kidunot89. And on the Slack channels on WooCommerce Slack I am there. You'll find me at Geoff Taylor, although I think it's @kidunot89 again. On WooCommerce Slack as well as the WPGraphQL Slack and several other Slack channels, GitHub or Twitter. You can find me at kidunot89.

Mendel: I appreciate so much your knowledge and you being on the show today.

Geoff: Thanks.

Mendel: And I appreciate your contributions to the community, because that's what makes things better, that's what helps us all upgrade our technology, our skills and the way we help clients and ourselves.

Greg says to contribute and shares the value he has found

Geoff: And also on that same coin, I also think people should contribute. Just like you said, with the giving back to the community. A lot of people just think about Open-Source and see it as you're giving away something for free. It is a great way to refine your skillset. As much as people will like to say that a commercial product is better or something because somebody's being paid to do it, it's not going to beat a community of people that are just, "Hey, we're doing it for fun, but we're bringing our skillset to it."

And contributing can easily help you refine as a developer as well as improve in just communication on projects and everything. I contribute. I'm trying to encourage others to contribute, and I think it's made me a better developer. I think it can make anybody a better developer.

Mendel: Cool. Yeah. Contribute, everybody. You heard it here first. Geoff does it, and if Geoff does it you should do it. That's all for this information-packed week. If you're enjoying this podcast please, please, please consider dropping a review over on Apple Podcasts. It would help us out. It'd help Bob out. It would help the community out. All those things. So go ahead and leave a review, and we'll see you next week.