The Five Ws of Decoupled Websites

Steve: Alright. The five W's of decoupled websites. Here we go.

Rachel: Hello. My name is Rachel Cherry. I am a freelance software engineer and online accessibility specialist and consultant. I am also the fair leader of this party and a director of the WPCampus.

Steve: My name is Steve. Our mission is to make the open web a platform. We hope that tooling will be a big part of how we go about fulfilling that mission over the next decade. If you are not familiar with Panthon, I was a pantheon customer before I was an employer. I liked that I could put in my code and get a test live and it worked well out of the box. If that sounds appealing to you, check us out at pantheon.io. This will be a relatively high level introduction to decoupled websites. We are talking about a separation of architectures and code bases that serve your code facing sites separate than a content editing experience.

We think it is to deliver the best possible user experience and a key part of that is being able to change the front end faster when you decouple. Ideally, doing a decoupled architecture will involve everyone on your team and anyone whose job it is to make changes to the site. When do you do this? When your goals align with architecture like this. The how is ideally one step at a time.

Diving in deeper here. What is a decoupled site? In short, we are talking about a split between content editors going from the backend processor, and it is separate from the general public going to the front access experience. Our front end is reading data from the back end CMS. To talk about the nuance a bit, one more specific model is a parallel dynamic run time. The idea here is that the idea is the split from the front end and back end. What run time is on each side is important. We have these built into PHP. Front end focused sites will be primarily in javascript. We will review JS components server side.

We can also do degressive decoupling. We have projects we have been talking about. It could apply just as well here. The idea is that we have a WordPress site and it has a header, body content, a side bar and perhaps we decide just this side bar section would be more compelling and better built and react with the working JS. Widget by widget and block by block, we decouple our website.

Another option is the hard split between back end and front end. The distinction here is that the front end experience could be static and compiled. It could be that when the general public is looking at the website, it happened at a quadruple word space and that is what WPCampus used. I will turn it back to Rachel to talk more about this.

Rachel: My part in this is that WPCampus decided to decouple our main website. You can check out the website. It is super pretty. The what in my story is WordPress. What is WordPress in this story? A coupled monolithic end to end content management system. It is drawing a picture of the back end that Steve was talking about with the front end. WordPress is all in one application that powers a back end interface to manage content and a front end environment to display it.

You have the back end. A lot of us are familiar with this admin experience. This is what the admin for the main website looks like. It manages your content and your data layer and your plug ins as well as lot spatial frequency meta data. You have your front end, which is where the public visit your website. It manages the design and the presentation of your website. It is very public facing. In a WordPress world, your WordPress theme may power your front end and javascript galore.

So, what are the pros of using WordPress in this particular content? Everything you need is together in one place. That is one of the most popular reasons why someone might use WordPress. There are lots of options included, plug ins, and themes to install. It is a great resource to have to quickly put together a website. Why is that a con?

Well, everything you probably don't need is together in one place. WordPress comes with a lot of stuff and you may not need all of it. The monolithic application can become quite bloated and sometimes hard to control if you don't know what you are doing.

The other what in our story is introducing Gatsby. It is a site generator based on react. It is more of a front end tool that is built to consume your content from WordPress and it will generate HTML in a build process that you can put on your server to display your content. It really prioritizes front end performance.

If you are unsure with how Gatsby works, it downloads your content from WordPress using an API. It pulls it down and downloads it. Then it intermingles it with your templates, your design, and your CSS. It creates HTML files that you would then place on your server. On your front end, as Steve mentioned, you are not really generally requesting information on the front end. You have already got the information and compiled it how you want it. Then you are displaying it. It makes your website very fast.

Why did we do all this and redesign? Our website was five years old. You want something new. We had outgrown our website a long time before that. We wanted to redesign our architecture.

Why did we want to decouple? We wanted more control and flexibility on our front end, the increased performance was a big part too. I was frustrated with plug in bloat. There were so many extra CSS and javascript files were being loaded on every page of our website even though they were not necessary. It was somewhere between 25-40 files. It is hard to control that in a WordPress environment. But in a Gatsby environment, you have more control. We wanted to play around with javascript and react. I wanted to become comfortable with web components, learn something new and play with new tools.

A refresher. Why do we need WordPress as an organization? One, we like to use it. The big thing is that we need WordPress. You need a way to manage content with multiple editors. This is why it is so popular in HigherEd. We need systems where we can have manage content. We have vast amounts of numerous data types, i.e. custom post types and stuff like that.

Why Gatsby versus Steven mentioned View or Next JS or whatever? I became interested in Gatsby because they have a high dedication to accessibility. I was intrigued with performance statistics I was seeing online. To group out the advantages of decoupling your website, you can really take advantage of these tools for what they were built for. Content management systems are built to manage content. Use WordPress as a powerful CSS to manage your data and make your admin sleek and prioritize how data is structured and have a good system. Output your data with the rest of API. Take advantage of tools built for front end performance like other tools that use them how you present your data. It can be really lightweight. You can have more control on what gets shown on your website. You have more flexibility to experiment with your framework. You have use different tools on your site because of how you separated your content from your design.

Steve: I have another angle on the question of why and starting to bring in the who here. Site visitors and the devices people are using to access these websites. As a web developer getting started in my career and new devices like the iPhone were coming out, I underestimated the scope of challenge like the iPhone or iPad brought in. We needed to do this on a slow mobile network. That is too narrow of an understanding. These devices are more than just a smaller screen size. These device developers are pushed to making users to fund the technology. The websites we built as web developers need to deliver more types of value in order to compete with native applications and often front end first or decouple architectures can put you in a better position to do that.

Some things we need to deliver for a university website is nearly every type of value for a website. A university needs to bring back students over and over again to the website. There is a need to encourage the next incoming class to apply to become students and you may need to sell sweatshirts online. The homepage of the university website often has slots built within it. They can be incredibly complex. The complexity and the need to compete on social apps requires the best tools available. It also requires that the people building the sites can focus time on the top reason the website exists and the impact it is there to create. It can be difficult to focus on the ultimate goal if the developers are overly focused on changes or making sure the website isn't crashing.

A big part of this is often because the deployment for decoupled architectures can become safer and faster. They go through this deployment timeline. Each of these environments may ask a different question. Ultimately what we are trying to avoid with a deployment pipeline is breaking your database or the live website in a damaging way. If a website has split such that the front half or public facing side is unlikely or incapable of breaking the database, then it may be possible to have a what step. You can make a change that is meant to make those networks and you can make it live in one step. Teams need to complete these cycles of changes to their sites faster and faster.

At one point, it was elite to make changes on a website on an every two week basis but the expectations for the changes are only rising. There are a few team members that benefit from faster shorter cycles of delivering and modifying changes.

The people asking for changes will benefit. If you demo a new feature to the stakeholder, they will want to see it on the website. They don't want to hear that their change needs to wait two more weeks to deploy. Designers can greatly benefit from this faster iteration cycle. If you can make CS changes and make them live near instantaneously it will make it easier to make iterations rather than trying to make something perfect without it ever going live.

Front end developers benefit most. They have been given an incredible challenge in the last decade keeping up with the number of devices, browsers, and nuance on the front end. It is no longer realistic to expect them to learn all the layers of WordPress. There are so many tools specific to front end development that have come out in the last decade. This is not arbitrary. This is front end developers recognizing that the challenge of building good websites is huge and has gotten significantly harder. That is why we needed this burst of new tools. I think react has come to the top.

I will go back to Rachel.

Rachel: The who for us was a working group once we decided the decoupling was what we wanted to research. The big important things for our teams was auditing existing content and functionality to make sure we knew exactly what we were getting into. As we will discuss throughout this presentation, it is work. We wanted to make sure we knew what we were getting into and researched potential concerns and limitations. I will talk more about that in a minute.

The where. It is important to recognize that if you are going to decouple your WordPress website, you might need a new hosting environment. You now need to host this very different set of files. WordPress is very PHP application and now over here in Gatsby Land we have HTML files with CSS and javascript. It is not that they can't be hosted together, but it introduces a new layer you will need to research. We reached out to pantheon since they have been a great partner of us for a few years now. We decided to go down this journey together to figure out how pantheon would host our decoupling environment as well.

Steve: It has been a common pain point. The assistant web developer needs to figure out where this is going. Many decide to put their applications on google cloud or azure. I am not expecting anyone to read this diagram. I just want to illustrate it is complex to take ownership of each infrastructure needed to run this. The front half requires nearly as complex. You are keeping that system administrator deep in the weeds and away from being able to focus on the top level reason that the site exists.

There are great front end focused companies out there. In talking with teams building these kinds of sites, I have heard over and over again that it can be difficult to have WordPress in one place and your front end or your Gatsby somewhere else and get repository on a third and fourth place. That is why we think we can add value by putting front end and back end in one place on pantheon. We are doing research on this now and development and we can share more information soon. We think that having this environment under one roof will be a big differentiator.

Where? One question I have been asking for a number of years is that if we are cutting off WordPress head, then where is WordPress's neck? The conversation that can happen between back end and front end developers in a monolithic site can get complicated as you try to decide which layer WordPress does a certain thing happen. Is it happening at the level of a Gutenberg block or a widget? When you cutout off its head sort to spk, you have a clear point at which you move data from the back end being sent out to Gatsby or any other framework. It can shape the conversation between front end and back end developers if we need to customize a certain component we can look and see if it needs to be a data component or a front end component after the data moves from API.

The site owner may start to ask questions as they hear these questions and talk about cutting WordPress in half. Why use it at all? WordPress has been managing content for nearly two decades. It is good at content managing roles and permissions. Also the open source nature of a WordPress should not be given up lightly. If we are chopping away the head of WordPress, the heart that is left over I think is the open source flexibility and control that you get along with the content management features that a WordPress is most well known for.

When is it a good idea to decouple? When decoupling will move you closer to your goals. That may be a line of design that will be difficult in monolithic WordPress. You may need to simply iterate on the front end independent of the front end. If you know it will not change significantly and you are unsure and you need to evolve it quickly, decoupling may be the way to go.

We have touched on performance. If you have a decoupled team and a clear line between front end and back end developers. Sticking to the theme of when, I would say please not all at once. Some teams I have talked to have gigantic sites that have built up layers and layers of complexity and their plan is to move their content all at once to Gatsby and druple nine at the same time. That is too much all at once.

Getting into how, it is important to validate some assumptions in smaller steps. Can you validate this in a small way by perhaps decoupling just a single page or component? If you have the assumption that they will collaborate faster, you could check that faster also by making a small change. Content editors may not know what they are getting into until they try it. You can set up an instance of them together and it could be worthwhile.

For Pantheon's own delivery plan, we have been working with a small set of customers on pilot programs and soon we will be doing custom delivery to our team and we are building out a full product offering coming soon.

Rachel, what is your answer to this?

Rachel: I don't have too much to add to what Steve shared. The when is a personal question. When you understand what is involved. There is work involved. Once you have researched how much work needs to be done, when you have figured out what hosting will look like, and more importantly when the move makes the most sense for your team. You can only answer that after you have done diligent research.

Moving on to the how, I do have very much a lot of information to share in that regard. We did a lot of work and learned a lot of lessons. One lesson we learned is that you are not in WordPress anymore. You are leaving the WordPress front end and therefore you no longer have access to HTML markup or functionality that belongs to the WordPress that belongs to third party plug ins. You no longer have out of the box applications. That was a big hurdle for us. You don't have built in live preview of content. These are just a few examples.

These problems can be solved. It is just a matter of how you solve them and how much work you are willing to do and what path you will walk down. The problems we face specifically is that we very much underestimated how challenging it would be to decouple web forms. Our solution ended up being for the moment implementing I frames because it was way too much work. We have a wide variety of forms. I am a big form of Gatsby forms because of the work they do with accessibility. We have many forms that have various field types and it would have taken months to rebuild the front end parts.

We ended up building a single sign on process using a WordPress plug in. Our WordPress environment is an authentication source for us. We also had to get rid of comments but to be honest, we didn't really use them. If you rely on comments, there are third party solutions you could use. I am not sure how easy it would be. For us, it was just worth it to get rid of the comments. We didn't really use them.

I was just going to run down the list of the tools that we used to solve all these problems and specific things we came into contact with in this project. We now had two websites and two applications. Therefore, we needed two website domains. We had a long conversation about this. We also have a multisite network. We could not change our main domain so easily. We used the headless mode WordPress plug in to get rid of redirects. If you are a certain usure, you can still access the front end aspect. Everything else gets redirected to Gatsby. We also have instances where we are using this to control some components. For example, the I frames we mentioned earlier. Some domains are allowed to access this. It helps us tell what domains can make it through and which domains are sent to Gatsby.

How we display the web forms is more specific. We placed gravity form short codes inside those said templates and used the URLs inside Gatsby as I frames. We got web components. It may be a javascript thing that helps us display those easily on the Gatsby app.

You have to download all your data to WordPress in order to feed it into the process. We have a few custom API end points that we use to really customize our data. The WordPress API is a nice tool but it does have limitations. If you have a lot of data or a lot of complex data, you might have to create your own end points. We use the Gatsby source WordPress plug in. But it is being updated. We might have to do some work on that soon. I lock down our WordPress API. You may not need to do that. I like the idea of doing that. We use the WordPress API dedication plug in and it does a good job.

I like our sign in process. It helps us better improve our I frame. When forms are displayed inside of Gatsby coming from WordPress, WordPress knows they are locked in and can populate fields. We like this functionality. I will admit that I forked it a little bit but not very much. Out of the box you may have able to use it to fit your needs just fine. On the Gatsby side, I used the module to handle and on the javascript side I didn't have to work it. We needed to figure out a way to trigger a new Gatsby field any time you update or trigger new content or change code. These are two different areas. One is a WordPress admin where we change our content and one is where we change our code. When we change code we use circle CI to trigger the build. Whenever we commit code, it triggers CI that Pantheon set up for us. When we want to trigger a build from oncoming content it allows us to have a button inside our WordPress admin and we have to go to the page in the admin and press the button. It is the same process. It triggers the build inside of our environment and syncs the final results to our server.

Our average build duration from me triggering the build to it being live on the website is a little over two minutes. It takes 30-40 minutes to set up the build environment. It then takes 50-60 seconds for the entire Gatsby build. The results were really cool to look at. We did a lot of performance testing before we switched to the decoupled setup.

I am an accessibility specialist. We were covered there. But our performance was really struggling and a lot of it had to do with what I mentioned earlier where we had javascript files we had to remove and manage and it was really frustrating. On the Gatsby results, the only one that is not 100 is performance one the only reason it got a 93 is because we had first launched. We were using google fonts to house our fonts. We will get around to it eventually and then we will have 100 across the board.

Cool. I guess we didn't work out who was going to say thank you.

Steve: We can thank each other.

I will put our faces back on the screen. Hello, everyone! I will look to see if we have any questions. I checked earlier.

We do have some questions that came in. We have two questions.

If we run a WordPress multi site network, is it possible to decouple just one website. Followup - is it a good idea? Yes that is exactly what we did. Campus has a multi site network with about twelve sites. This Campus 2020 site is the most recent one and it is number twelve in our ID. We have had this awhile and it runs great. We love it. The site is the root site and it is the number one blog site. We were able to do that with the only remote. There was no drama about it. We just ahead to come to a decision about domains. I wanted to switch and I wanted the WordPress to have www. I don't like them in our domains. After talking to Steve, he told me it would be complicated to switch that out and not really worth it. Yes it is possible. It works just fine. I hope that answers your question. I would not let that stop you. Did you have anything to add to that, Steve?

Steve: I think that is the way to go. Start with one to validate that. The change is worthwhile. I wouldn't want to decouple and then find out that this was not exactly what I thought I was getting into.

Rachel: Can you imagine decoupling all the sites on our network? I can't imagine. Every other site on our network is WordPress and it works just fine. Maybe one day we will move it, maybe we won't. We really enjoyed the process. I wanted to give a 2020 site into Gatsby but there was not enough time to do it all.

One more question. If you were building a brand new decoupled site today with no existing content, would you still choose WordPress as the CMS?

It depends on the site. I mean, pick the tool and the right tool for the job. While we all love WordPress, it is great. But it is not always the right tool for the job. Sometimes you don't need a monolithic CSS type system. Maybe it is just you managing your content or you and one other person. Maybe you want to manage your content in a GitHug way. There is tons of ways to manage content and do it in a way that is controlled and user managed.

Steve: I think putting all the content in the same git responsive like Gatsby can have advantages. There is a company that has a site that will be a brochure website that will be important for a short period of time. That is it. Doing all the content inline in the same git repository is a better option. It is split and it is valuable over long term when you have content editors signing in. But if you have a small team building a website and you need to get it done as fast as possible, it can be okay to have a messy mix of content. The hard separation between what is content and what is code is sometimes valuable. But for a site that is only relevant for four months, it may not provide value at all. After those four months, the site can sit in perpetuity and that is the safest and often cheapest way to run a site.

Rachel: My personal site is just the Gatsby app. I post my content in markout files. I don't need to manage an entire WordPress application for my eight page portfolio site. It really depends on your site.

Before we go, we are the last ones. We can go over a couple minutes if we want. We have one more question. What are security applications of decoupling? Pros and cons?

Steve: One pro is the front end experience can be done as all static files and you can run WordPress behind a firewall. As Rachel mentioned, you can put a password on the Rest API and make all the content not directly accessible. Cons. You might want WordPress publicly available and you may run into cross domain complexity and pitfalls.

Rachel: Basically, we still ended up having a fair amount of front end real time interaction between our Gatsby and our WordPress especially with wanting to have single sign in for user authentication and setting all that up. You could almost say there is more information coming out of our WordPress app then there was before. It is being sent out to other websites than there was before. You need to be mindful of that and protect your data. If you are going to have the set up where the API is not accessed on the client side, there is less concern. You can still lockdown your Rest API and give the Gatsby a password kind of thing. I would be mindful of the fact that in a decoupled world, or heading when that path you are having more exporting of your data from your site then you may have had keeping it all within the WordPress family sort to speak. Be mindful of the kind of risk you might be opening your data up to.

Alright. That's all I have. Thank you Steve, for doing this with me and for all the help you've given us on our project.

Steve: Thank you, Rachel.

Rachel: Bye everybody!