WordPress headless Project and how to deal with

Source: Dev.to

Hey everyone! Our team and I (acting as a junior backend) recently finished rebuilding GlobeVM (an enterprise Cloud, IT, and Cybersecurity provider) from a traditional monolithic WordPress site into a Headless architecture. I wanted to share our entire journey, our tech stack, the massive headaches we faced, and the solutions we engineered. If you are planning a Headless WP build soon, grab a this might save you weeks of debugging! Frontend: Next.js (App Router), React, deployed on Vercel. Backend: WordPress hosted on Cloudways (Purely as a headless CMS). Data Structure: Advanced Custom Fields (ACF Pro) + Custom Post Type UI (CPT UI). SEO: Yoast SEO Premium (via REST API). Caching: Vercel Edge Cache (ISR) + Redis Object Cache on Cloudways. During the development and deployment of this website we faced several issues containing the frontend stack itself and traditional features of WordPress. I tried my best to save them all and show them all up here for everyone so that we can discuss on every section of it, maybe we could reach to even something more special :) When we first started, we were using the default WordPress REST API. Our Next.js frontend was making 8 different fetch() calls just to build the Blog Homepage (fetching posts, authors, categories, tags, ACF fields, etc.). We were also using messy URLs like ?_fields=id,title,acf&_embed. The Solution: Result: Next.js made one fetch call. The page loads instantly.’ Our design heavily relied on custom SVG icons for our Service Cards. But WordPress blocks SVG uploads by default for security. Furthermore, getting ACF Image fields to play nicely with Next.js was tricky. The Solution: We had strict rules: Comments needed Admin approval, and threads could only be 1-layer deep (no replying to a reply). The Solution: We wanted a “Popular Articles” section based on view counts. But because Next.js uses ISR (Static HTML), WordPress doesn’t know when a user reads an article! The Solution: How do you let an admin click “Preview” in WordPress when the frontend lives on Vercel? The Solution: When we went to production, Next.js was caching the frontend, and WordPress was caching the backend. When an admin updated a post, the site wouldn’t change because WP was feeding Vercel stale JSON. The Solution: NOTE: This is about the ISR system as far as we understood, There are two ways to implement the ISR, On-Demand and Time-Revalidation. First one is about to set the NextJS in a way that it stays for the demands (requests) and then refreshes itself. key point is right here, the first visitor see’s the cache and the second see’s the updated version. with this mechanic ISR gives you the speed of SSG and somehow the live form of SSR caching system. Finally Time-Revalidation is about to set a timer in order to refresh the cache exactly as i mentioned in the previous one. In this strategy you set a time for revalidating the cache and then the webhook is going to be send from wp to next in order to receive and fetch the fresh data. In Headless, you can’t just rely on Yoast to inject  tags. Building a Headless WordPress site is not just about using fetch(). It requires treating WordPress strictly as a Database and taking total control of your REST API architecture. if your are keen on finding out some massive project examples i would like to suggest you visiting these websites —> https://www.aljazeera.com/ & https://www.bbcamerica.com/