Do you need Headless Wagtail? A guide for decision makers
Here is a handy guide for decision makers who are considering Headless Wagtail.
A quick review of traditional vs. headless Wagtail
In a traditional Wagtail website, almost all the technology you need to make the website work lives on a single server. In this one-server-to-rule-them-all structure, the database that houses your content, the stylesheets that make your website look pretty, the ecommerce code that lets users buy things or make donations, and the rest of the code that makes your website work is all in one place.
Headless Wagtail is set up like a jamstack. In a jamstack, the backend (things like the database and the editor where you make changes to your content) is separated from the frontend (things like styles that affect how your website looks and the forms users use to make purchases or update data) and other services (like authentication or ecommerce) that make your site run. Of the headless Wagtail setups that have been created so far, typically the CMS portion of Wagtail and the database are hosted on one server, the frontend portion of the website is hosted on another server, and there's an API that connects the two parts together that lets the frontend pull content and data from the backend.
Who uses Headless Wagtail right now?
Currently, there are governments, nonprofits, and publications using Headless Wagtail. Here are some examples you can explore:
There are also developers who've released experimental templates for Headless Wagtail and other projects. Here are two examples from GitHub:
Upsides to Headless Wagtail
You can do more with your content: With your content API, you can reuse the same content in multiple frontends. For example, the same blog content can feed into a website, a mobile app, and apps for devices like smartwatches.
A lower risk that your entire website will go down: Because a Headless Wagtail structure is distributed across multiple servers and services, there's less risk that your whole website will go down if there's an issue with the primary server.
Scaling is more manageable: With Headless Wagtail, you don't have to think about building for multiple devices all at once. You can pick what devices you want to target first and create new frontends as you learn more about your audience's device preferences.
More options for developers: With Headless Wagtail, developers would be able to use API calls to pull content into their preferred web frameworks and frontend tools. They would have more flexibility to use tools they already know.
You're not locked in: Having your content separate from your frontend code will give you more options to upgrade and update your frontends. That can help you keep up with changes in technology and give you more flexibility to try something innovative and new.
Downsides to Headless Wagtail
Everything won't be in one place: A Headless Wagtail setup will require you to keep track of multiple services and vendors. If you can't afford to work with an agency or technology partner, you'll likely be managing this on your own.
You'll need a different approach for managing previews: One feature editors enjoy about traditional Wagtail is the ability to preview content before it's published. With Headless Wagtail, that's currently not possible and you'll need to come up with a custom approach to preview content in each frontend.
Costs are currently higher: Headless Wagtail requires a larger initial investment to set up, and because there will likely be multiple services and frontends involved, the ongoing costs will likely be higher as well.
You'll need developer support: A traditional Wagtail site is manageable for a single developer or a small team of developers who are familiar with Python. A Headless Wagtail setup will require more specialized knowledge to maintain and the issues that need to be troubleshooted will be more complex.
Replicating the complete system in a local environment is harder: A traditional Wagtail site can be easily tested on a local machine in a test server or container. A Headless Wagtail site could potentially be tested locally, but it would be harder to replicate your site's full functionality if it has multiple distributed services or integrations.
Personalization will be harder to accomplish: Currently, personalizing content is difficult to achieve in Headless Wagtail because of the rendering code that's involved. That will likely change as Headless Wagtail evolves.
How to choose which approach works better for you
Now you know some of the main upsides and downsides and downsides of Headless Wagtail. So how do you make a decision? Here are some questions you can use to help you brainstorm the best approach for your project and start a conversation with your favorite developer, agency or technology partner.
Do you need content on multiple devices or multiple websites to accomplish your goals?
If you're looking to create a blog or publish content primarily to one or two places, then Headless Wagtail might be too ambitious for your project. If you need to distribute the same content on a large scale across dozens or even hundreds of platforms, then Headless Wagtail could ultimately save you the time and effort it takes to modify content for each unique platform.
Do you have a tight budget for your initial launch?
Headless Wagtail requires a substantial upfront investment. So if your budget is tight, you might want to start with traditional Wagtail instead. Starting with traditional Wagtail also gives your team more options to experiment, test, and make adjustments to Wagtail to suit their workflows. You can always invest later in creating the custom code that will be needed to convert your project from traditional to Headless Wagtail.
Do you have developers on staff and do they have the skills to help support Headless Wagtail?
You will definitely need in-house technical talent to manage a Headless Wagtail project if you don't have an agency or technology partner to collaborate with. If you do have developers on staff, check if to see if they have experience supporting APIs. Be sure to ask if they have experience with managing multiple versions of an API and whether they're capable of maintaining a development API in addition to a production API. While APIs simplify many things, there are still challenges when it comes to coordinating changes across multiple platforms that developers who build APIs tend to be more aware of.
Will you be working with an agency or technology partner?
If you can afford to work with an agency or technology partner that has experience with Headless Wagtail, your project will be much more streamlined and manageable for you because they will take care of managing all the different pieces of your project for you. If you have the budget for it, this is currently one of the best options for organisations that want to invest in Headless Wagtail.
Will your project require ecommerce support or other integrations?
The more services and integrations your project requires, the more parts you'll need to keep track of in your jamstack. If you have access to technical resources or developers who are good at making different technologies function well together, then Headless Wagtail could be a good fit. Small teams with fewer technical resources might want to consider a traditional Wagtail setup.
Are you comfortable with newer technology?
Headless Wagtail and other headless CMSs are pretty new, so there will be fewer developers and agencies with experience supporting them. If you absolutely need something stable and well-tested, then traditional Wagtail might be a better fit for you. But if you're comfortable with using new innovations and are patient enough to deal with new issues as they arise, then the benefits of Headless Wagtail could make this approach worth pursuing for you.
Who can I talk to about Headless Wagtail?
Here are some agencies you can reach out to if you'd like to find out more about Headless Wagtail.