Product Build Breakout Summit/2020: The Future of Headless
Matt Landers, Technical Architect, WP Engine discusses:
- What is WordPress Headless? A traditional WordPress web architecture vs. a Headless architecture.
Headless WordPress is any configuration where WordPress is not responsible for rendering the site.
Full text transcript
– Hi and welcome. I’m Matt Landers, technical architect with WP Engine over our Headless products. And this is the future of Headless.
Right, so before we dive into what Headless means for WP Engine, why don’t we talk a little bit about what exactly Headless is.
So Headless is any WordPress configuration where WordPress is not responsible for rendering the front end site. Meaning that when your users hit the site, they’re not hitting WordPress, they’re hitting something else that’s responsible for showing that website to them.
WordPress is still responsible for other things though, let’s look at these architectures. This is your traditional WordPress architecture where you have your content producers on the right hand side they’re entering content into the WordPress Admin.
And then WordPress itself is rendering out all of the content so all of the images, all the pages, everything is being rendered by WordPress itself. Then your visitors are hitting WordPress now a little bit more complex environment might look something like this where you have a CDN in front of all your static assets.
So your images, videos, whatever else that you wanted to be static could be on a CDN.
And then sometimes your user, your visitors might hit the CDN. Sometimes they might hit WordPress itself, and your content producers are still putting stuff into WordPress.
Now, this would still be a traditional WordPress setup, like what you might have a WP Engine.
And in a Headless architecture, this gets changed quite a bit. So you still have your content producers on the right hand side entering content into WordPress on the back end, but then your front end is being handled by something else. And in this case, what we’re seeing here is Node.js.
So what we’ll call this sometimes is your back end for your front end, where Node is serving
up your front end assets like maybe your react app, your view app, whatever it might be.
And that’s what the user is actually hitting. They still have a CDN in front of that. But they’re hitting that Node app for the dynamic pages that are being displayed,then the Node app is talking to WordPress, or in some cases, you could even have your clients speak directly to WordPress through the API.
Alright, so this is what a lot of our customers have said that they’re doing whenever they’re doing Headless themselves, they might have a WP Engine install that then they’re having to host their front end somewhere else.
And that’s not ideal, because if you’re gonna, if you’re an agency, and you need to transfer that over to the client, you know, now you have two things that you need to transfer over or have two things that you need to manage in different places, you’re not getting the same support, potentially from that other host.
And we wanted to make this a unified experience for our customers. So let’s talk about what that looks like.
The Headless at WP Engine. This is what I’ve been working on for the last good while and I’m really excited to finally be able to talk to everyone about it.
But you’re gonna be able to host Node applications in auto-scale environment at WP Engine. And what does that mean exactly?
So today whenever you get an install from us or WP Engine site, you have a box that you can FTP into, you can set up your own deployment mechanisms, however you wanna handle that.
In the Node environment, it’s gonna be different. I mean, it’s something that you might see it some other providers where we’re gonna hook up to your GitHub account.
And we’re gonna watch the repo and the branch and based on the branch, we’re going to deploy the right environment.
So if you have a production install of WordPress, then you’ll have a production app, a Node app that you can install. That will be directly pulled from whatever branch you assign to that environment.
Same for staging prod, or however many different environments that you have for your sites.
And you’ll be able to manage all this through a CLI that we’re providing to you, through our portal and through an API.
So if you need to script anything. For instance, if you have a Gatsby build that you wanna kick off a certain times, you could do that through our API, without necessarily having to push to GitHub to make that happen.
So now what our environment looks like is something like this, where we had that Node, front end there with the WordPress in the back now.
WP Engine is able to handle all of these things for you.
We can handle your CDN, we can handle your Node and your WordPress install, and you still have these other services that you might integrate with. And you would do that in whatever manner you wanted to.
But now we’re gonna be able to host all of these different things at the same location,
with the same support and everything that you’re used to from WP Engine. So I’m really excited to jump into that.
Now before we get into the demo just a quick note, if you would like to participate in our alpha that’s gonna be launching very soon, just after summit. Please reach out to your sales representative. And they will help you get in touch with the right person, probably me or Brandon, and you can talk to us about what you’re trying to do and we can potentially get you into that alpha as we lead up to launch and (mumbles) for our production building.
So with that, let’s dive into the demo and see how exactly this is gonna work whenever you start building these apps on our platform. All right, it’s demo time.
And the first thing that I wanna do is to set up what we’re gonna do in this demo.
So I’ve written a little site here with niche.js. And what it does is it pulls in blog posts from multiple different WordPress sites. So we’re gonna pull in development related blog posts, from wpengine.com and torquemag.io.
And based on the categories on those posts is what we’re gonna pull in.
So we’ve made this completely configurable, so I can put in other blogs in different categories,
and that’ll change what’s actually pulled in as configured the environment variables. So let’s take a look at how the application actually looks. And then we’ll dive into how the application actually works.
So let’s start the application, well the npm run dev, and that’s gonna spin it up on my local machine here, which will pull up here.
But the homepage gets statically generated at build time. And the post pages get server side rendered whenever they are navigated to.
So we can see on the homepage, we have a list of all the blog posts that we’ve pulled in.
It has where they came from, at the top here, we have TorqueMag, we have WP Engine.
Then we click on one, we see the actual post.
And if we click like TorqueMag, it will pull up the original post there.
So it’s a simple little site, but it’s a pretty good example of a headless site and that it pulls from multiple WordPress sites into one. It’s statically generated and summarized.
It’s server side rendered, it’s very performant and fast.
And we wanna be able to deploy this to the WP Engine, headless environment.
We’re gonna look into that for the most part, but I wanna show a little bit about how the app is written first.
This will be on my GitHub. So if you wanna check it out and see how it’s built, go for it. And give me any feedback that you have.
So let’s take a look at some of the pages. So the homepage is rendered, is rendered completely statically. So that means that at build time this page is created.
So this is important when we think about how we deploy this because the server requests, requires those environment variables in order to get back the data that this homepage needs.
So that happens at build time. So we have to have a way to specify those environment variables
for whenever we’re building this.
So what we’ll do on the platform is pull down your code, set those environment variables
and then build your code and they’ll be there for you at that time.
So that’s how it gets(mumbles) works is it builds it statically and saves it and then the user is always served as static page.
Then on our posts, we’re just doing server side rendering here. And it also calls the same sort of API’s and requires that those environment variables as well, at runtime.
So these are available at runtime for this page. And this is the page that just shows different posts. Alright, so that’s pretty cool on how this works.
Now let’s take a look at how we would deploy this. So the first thing that the platform does is we pull down your code based on your repo and branch, and then we run NPM install, so that’s gonna run, install all of your dependencies.
After that, we run this script wp-build. So this is your opportunity to call API’s at build time to do
whatever you need to do during your build.
And we’ll have those environment variables ready for you at that time.
And then whenever we’re ready to run your app, we will run NPM start. So this is your hook to do whatever you need to do at build time.
And that’s important because you’ll, that’s where you’re gonna wanna build your app at that time.
Alright, so now let’s look at the CLI to actually get this deployed. I’m gonna pull up another command prompt. And we’re gonna run wp alpha, and this will show all of our options in our headless CLI, we have apps, auth and builds.
We’re gonna mostly talk about apps in this talk.
But I will briefly go over what auth is, so auth is so that you can connect your WP Engine account to the CLA and authenticate. And it also lets you connect your GitHub account to your WP Engine account.
And that’s important so that we can put on your code, we can add the hooks and so that we know when you pushed your repo.
And we can rebuild and those kinda things. Alright, so I’ve already authenticated, so not gonna get through that process.
But let’s go ahead and run the apps command.
So wp alpha apps. And this will show us everything that we can do with the apps, we can create an app, delete an app, get an app, list all of our apps, we can rebuild an app.
So this is an opportunity to just kick off the build, even though you may not have changed the code. So in your wp-buildstep, you may be reliant on other systems where their data may have changed that affects your build.
This is your opportunity to kinda have a hook into that. And we have an API that
you can call here to, to kick that build off automatically, if you want it to or just do it with the CLI
and then you can also update your apps.
So we’re gonna create an app. So let’s go ahead and see what that shows.
Here we can pass in the name of our app, you can pass in the repo.
And then we can pass in our environments. We can also just do this with a config file, which is how we’re gonna do it here.
So when you’re creating an app, it’s probably easiest just to do it with the config file.
And I’ll show how that looks. So let’s go to our code.
I have a wp.json file that I created. File name doesn’t matter, you just need to know what it is. So you can pass it into the CLI tool. The configuration does matter.
Now all of this is subject to change coz we are an alpha.
But I’ll show you how it works today.
So at the top level, we have our app name, you can think of this as a site in WP Engine Land for a WordPress.
And then we also have a list of our environments. And you can think of
those are exactly the same as environments are WP Engine Land. And they’re actually matched one to one.
So our app name is Headless Summit 2020. And at that top level, we
need to specify what repo we want this app associated to, and it’s my GitHub
account, manage landers. And then it’s headless-summit2020.
So that’s the repo that I am associating into this app.
And then I have two different environments, specified are my production environment,
and my dev environment.
My production environment is tied to the master branch of this repo. And then my dev environment is tied to the dev branch of the repo.
And I also have my secrets or environment variables, and the categories and blogs exactly like
what we have in our next config here, where it sets the environment variables locally, we can set those in on our app.
So we could, without changing code, come here, change environment variables and kick off a rebuild, which will do automatically for you if you ever change environment
variables, or the branch associated to your app.
Okay, so since we don’t have any IDs in here or anything this is gonna just create
a completely new app with two different environments associated to it.
So let’s go back to our command line and get that running. Alright, so clear this and we’ll say,
create -f wp.json. And what’s gonna happen is that’s going to go out to the platform with this config, and create a new app.
So now we have this app has come back. So we’ll run alpha apps list.
And we’ll see that we’ve added this new app.
So let’s pull up this app. So it’s a wp alpha apps get and pass in the ID.
I’ll see everything about this particular app.
So I can see my environments. Now I have my dev environment and my production environment.
And whenever this URL shows up, that’s when you know that the environment is actually built
and your code is running so that quickly our code has already been built.
And it’s been deployed to our environment at this URL.
So this is our dev URL. So let’s go ahead and copy that and go take a look at it.
Alright, and there’s our dev environment. And this also has HTVS, automatically set up for you.
So everything that you do on this platform, gets a certificate from Let’s Encrypt.
And then let’s also look at our production environment, make sure everything’s good to go there.
We can have that build, running. And we’ll check out make sure.(mumbles)
Awesome, very cool. So just that easily, we’ve deployed a new app to our platform.
Now, let’s look at how our development workflow might go.
Let’s say that we wanna change this test here on our dev site.
Let’s go over to VS code, blow up our homepage.
And instead of saying how is WordPress and content management systems, we’ll just change those to and modern app development, we’ll save that, we will check it in so add that, commit it
there’s the very descriptive tag.
And we’ll push that up to our repo. And then what’s gonna happen is the platform is gonna see
that that change has been pushed to the repo tonight, kick off a build process, and then it’s going to redeploy it for us.
So let’s go back over to our site and wait for that to happen. Now, there might be some caching here.
So I’m gonna open my dev tools, and add an empty cache and hard refresh until this happens,
so I can see on my dashboard over here that for the platform, that it’s actually still building and deploying.
So let’s give that a second to happen. During the build, and now it’s pushing that build after we’ve, after the build that pushes it up to the platform.
And then it should be ready here in just a second. All right, should it be good now. Well let this kick so it has to drain all the, has to drain everything from the current running process until we get the new one as running. And there we go.
So that’s pretty cool. Our site never went down during that process.
You saw me sitting there refreshing. And then as soon as the new build was ready and available, it switched over to the new build so that easily we can have this really cool development workflow where we’re building, pushing, seeing our results, and then whenever we’re ready, we can merge that into prod and earn to master and then that would be deployed
to our prod URL over here.
All right, cool. That’s our development workflow. And that’s how easy we expected to be for you.
And I’m really excited to see everybody, like, dive in and be doing this on a regular basis and give us feedback on all other things that we can be doing for you.
Alright, so one more thing that I wanna set up.
We don’t want our production URL to be that crazy URL that we saw, we want it to be something
that anyone could type in. And I have a domain that I’ve already configured with the platform.
But I’m gonna add that to this actual to this app in this environment. So I’m gonna add a domains tag here.
And I’m gonna add headless.news, that’s the domain. And we also need to pull in our IDs
because if we don’t pull in our IDs, we’re gonna create completely new environments.
And we don’t wanna do that coz we use this, whenever we were doing our create, so our
dev environment has an ID.
And we’re working on having prettier names for your IDs, allowing you to specify that.
But for now, you get this crazy random ID. Alright, so this is our production one,
so I’m gonna go ahead and come over here.
And I’m just doing this so that we don’t create new environments. I’m gonna need to pass in the ID.
So that we don’t. Alright, cool.
So now this file is ready. Now we can run an update command on this file, and we’ll add that domain to our environment.
So let’s go over here and we want to grab this ID, the ID of the app. And we’ll run WP alpha apps update.
We’ll pass in an ID and then pass in the file that we wanna use to update.
We’ll run that and then it, I didn’t get an error or anything. So we’re good to go.
Let’s go over to the browser and type in that awesome URL.
What should happen is this will connect to our production URL, our (mumbles) environment,
and also provision an SSL certificate for this new domain as well. So let’s go check that out.
And there we go. That easily, we’ve added a custom domain to our environment.
And we’ve got the SSL certificate all set up for us. And we’re ready to go. Now we’re ready to start building in our dev environment.
Creating PR’s or merging into our production environment, and having the platform just completely take care of all of the deployment for you.
So I’m really excited to see everybody get into this.
If you want to be part of our alpha, please reach out based on the contact information that we were talking about in the presentation.
Talk to your sales rep, we do have a process around who we’re deciding to pull into the alpha.
And then we’ll have a more generally available product ready later this year, well we expect to be doing live sites on the platform in the fall.
So I’m excited to find some of you to work with us to get some of the, some of our first sites
on this platform and running.
And have everyone start to play with it and give us feedback so that we can make it the best possible headless experience for WordPress.
There is at all.
All right, get out there and start writing some headless apps and make sure you send your feedback to me and I’ll be interested and talking to you about what you’re doing.
– Everyone and welcome to the Q and A section for the future of Headless. I’m your moderator David Vogepohl and I’ll be asking questions of our illustrious presenter here Mr. Matt Landers.
Matt, that was amazing presentation. Thank you so much for presenting it. We’re actually have a real good number of questions here from the audience.
Please feel free to continue to ask those questions.
Our folks are monitoring and will give us basically feed those questions here to us here live for the event.
So the first question comes from Chris, why would I use WP Engines version of Headless Hosting over something like Netlify? Is it the consolidation of the platform with WordPress in the front end or like help Chris understand why they might use WP Engines future offering or Headless?
– Yes, so we’ve heard a lot of feedback from our customers that when they run Headless, they
wanna be able to have their WordPress environment and their front end hosted in the same place so you don’t have to manage two different accounts.
If you have any issues there then we can’t help you with that. We can also set up you know private routes so that we can block your WordPress instance off of the internet where only certain people could get to the admin.
And then have Node be the only thing that can talk to it from the internet.
So you could secure WordPress that way. So there’s a lot of different options that you get by being with us. And then we can also do some WordPress specific stuff in the future, like maybe
automatically authenticate you to WordPress, so you can do previews.
Since we know your WordPress install, we can do those kinda things. And I put some of that pull (mumbles) for you.
in the same place is obviously a big ask of people running headless environments or Headless applications.
So next question is from Josh. Josh is new to WordPress development. Welcome, Josh. He’s only been added a couple of years now. But he’s trying to get his head around Headless and he’s asking, does it pretty much make WordPress just a really good admin or back end?
– Well, it makes WordPress a headless CMS. So there’s a lot of these headless CMS is pop popping up. It just WordPress is well known by marketers and content producers. It provides the authentication and user support.
So there’s a lot of things that WordPress gives you outside of just rendering your website.
There’s a lot of authoring workflows that are built through WordPress, that a lot of these other newer CMS’s just don’t have in there, you know, they aren’t part of their CMS yet.
So there’s 15, 20 years of WordPress development that you have to take advantage of, but then you can go use modern tools and technologies to build your front end.
– Yeah, that familiarity on this content creators is so important.
Having custom workflows, having familiarity, so that anyone you hire
has that knowledge. So for those, this question actually has kind of been asked maybe by a bunch of people.
Where like there’s some confusion around the concept of Headless.
And why does this matter?
Like why would someone go through the trouble of adopting this new way of building with their WordPress sites?
– Yeah I think that there, right now, I would say that the stage where Headless is, it’s more for advanced sites.
And a lot of the modern websites are being built using modern frameworks like. React and View Angular, those kind of things.
So we’re seeing that for one, a lot of people just want to develop in those languages rather than going into PHP world. And then for the more advanced sites, they’re also looking for security speed.
And in those integrations so here’s a lot of different reasons that you might choose a headless site. But if you just have, you know, a basic site that’s not doing a whole lot, probably doesn’t make any sense for you to go headless yet, until there’s more support around that.
But of course with WordPress in being such a popular CMS and being so flexible, those teams are often landing on WordPress, which I think gives a lot of advantage in that space.
This next question comes from Lucas. Lucas is wondering, will pushing the front end piece also purge cache on the WP Engine platform that’s hosting that data? [00:26:01.04]
In other words, what purge the cache from the WordPress back end?
– Right so right now we’re not doing anything specific for that. But that’s good feedback
that we can take in and look at if it’s something that we need to do.
– All right, next question comes from JB. And JB. Welcome back to the Q and A.
I remember you were there for a local session, why does the human readable domain not reflect your changes to the title?
– Okay, so I had a dev and production environment. When I pushed my code, I
pushed my dev environment, and I had a different URL.
So I didn’t hook a custom domain up to there.
So your development workflow would be, I have my dev environment. I’m on my dev branch and GitHub, I made my changes, push it to my remote branch and GitHub.
Whenever I do that, I can go check the dev URL to make sure that everything still looks good. Whenever I’m ready I can merge dev into master and then that will, that will then update the actual instance that’s running the production build.
– Alright, good deal. Next question from Matt, another good one. Does traffic to the headless app still go through global edge security?Or does GES sit between the app and WordPress?
– Yeah, so we’re gonna take advantage of a lot of infrastructure that’s already in place that WP engine so we’ll be going through the same routing that we do for our WordPress sites.
– All right, good deal. Next one is, I love this name from Cracker and Cheese. How will this offering be priced?
– That is a great question
and we will get back
to you on that–
– That’s TVD,(laughs)
All right, we were doing
these live Matt.(Matt laughs)
Next, well actually,
you know what?
– I’m not authorized to talk about them.
– We are at the end of time. Matt 70 questions like streaming in here.
So if you have questions left for Matt and Matt again thank you so much, wonderful wonderful presentation, but if you can go into wpe-events.slack.com and check out the headless channel,
I’d be picking up the conversation there.
Thanks everyone for joining us for the session and just the WP Engine summit in general.
Really, really appreciate y’all attending and I’m really enjoy, you know, having conversations there slack and Matt congrats again, wonderful presentation.
And I’m gonna be posting that link to a forum to apply to the alpha program and the chat as well.
– So great mention. Thanks Matt, thanks everybody.
– All right see you.