Welcome to the WP Decoupled blog and the #BuildInPublic series!
This series will document the process of building the WPDecoupled site and the thought and knowledge that goes into our technology decisions. Our experience is that folks don’t usually lack options, in fact, they have too many. We hope that sharing our experience and process helps provide valuable insight as you sort through the myriad of options.
Table of Contents
Preparing for Launch
There’s a lot to think about and do when launching a site like this one. It’s very iceberg-like, most of the work is unknown at the outset. This means reducing the amount of known work was paramount, baby steps, per se. I also wanted to be able to share the process in this very series. That meant getting a bare minimum site launched to share as I continued to build.
v0 was going to be really simple. The goal here is to get a site public and share about the project. Because our content would be non-existent to start I also wanted the ability to let folks know when the content started getting published. Collecting emails seemed like the best way here.
Choosing the technology
Decoupled WordPress as our back-end technology was given. My background is all JS front-ends like React and Svelte, so I knew I wanted to pick a front-end framework to utilize those skills. This would give me the ability to create a variety of experiences for my users down the road. Much of the site will be static content, but I have ideas for tools and such that would be very dynamic. A JS meta-framework that allows for server-rendered and client-rendered content means I can optimize the delivery as needed.
Tech specifics aside, I generally prefer Svelte over React. This is a highly personal opinion, while could gush on Svelte and its superiority, most of it would just be preferences. React/Next.js would have made a solid choice, and many things would have been made easier given the ecosystem and work companies like WP Engine are doing on the Faust.js framework for decoupled WP. So, because of my preference, and evident masochism, I choose to go with SvelteKit which just reached a v1.0.
This left collecting emails. While it was tempting to go grab a SaaS product, WP is well suited for this task. Reminder, I wanted this to be as easy as possible. That meant not learning PHP and WP to build a custom solution. There are a lot of great form plugins. Because we are working with a decoupled front end, I needed to be able to submit the form data via a REST or GraphQL API. This left Gravity Forms or Contact Form 7 as viable options. I decided Contact Form 7 met my needs and was the simpler of the two options to implement. SvelteKit’s actions meant easy server-side handling of the form submission and passing it back to the WP server via REST API instead of messing with GraphQL. Gravity Forms is a GREAT option, I might switch in the future as my form needs increase, but for the moment, I’m focusing on short-term needs.
The last issue was Contact Form 7 doesn’t save submitted data, it is designed to immediately email or otherwise pass on the data to a 3rd party system. Thankfully, plugins have been built to save this data directly into the WP database. I added the Contact Form CFDB7 plugin to the install and my form submissions were now being saved and could be exported later when I wanted to use those emails.
Picking a host was a pretty easy decision for me as I use to work for WP Engine on their decoupled WP platform “Atlas”. While any WP host would have worked WP Engine’s investments in caching for WPGraphQL, search, and front-end hosting make WP Engine Atlas a great choice for decoupled WP hosting. Full disclosure, they also kindly agreed to sponsor my hosting for free for the first year. Their continued investment in the headless/decoupled WP eco-system is commendable and I could not ask for better hosting to get this site started. Thanks, WP Engine!
The journey ahead is long, and I have lots of prose and code to write, I hope you’ll join me for this decoupled journey! Thanks for reading this far!