Headless problems on WordPress

Here is a small overview of common problem of GQL VUE/React(Headless solution) and the like coupled with WordPress.

In a nutshell. Making website on WordPress and Vue/React is stupid in first place. It drastically increase the development time, the price, people needed every single thing of the website, like 10 times or more in the development and it can cripple any other later improvements as the complexity is absurdly high.
Here is why…

Headless cons:

# can’t or hardly can check broken links, which is a crucial thing at several places in the development and production process

# url can and will collide, e.g. /department/contact and /department/abc/contact etc., the solution is to use the ID in the url everywhere, it is necessary to reach things always based on the ID not the slug etc. In other words the two way routing logic is simple a project killer.

# The backend doesn’t generate the correct url in case of a view preview. There is a hack for that, but it is too complicated and not 100%. The complication is the need to modify the url from the backend to the frontend url only in selected cases.

# Decreased comfort when editing pages, when the editor often ends on an empty CMS url instead of ending on an adequate frontend

# GQL slow initial page load time ±2.5s instead of ±500ms as the VUE app needs to be loaded on first hit “all”.

# not optimized queries to the database. even due to non-optimal implementation on the GQL side, it can be problematic with higher load/usage

# due to the use of GQL it is necessary to deploy at least 9 more plugins, which of course slow down the overall operation of the site for both frontend and backend
while plugins that solve the integration of ACF meta, ACF taxonomy, etc. are developed separately and are therefore not fully compatible

# duplicated frontend backend solution overloads the solution, because there are 4 things to be solved in each level – backend, frontend, server, and concurrency, which is another person, i.e. 4 people instead of e.g. 2

# almost any modification on FE requires unnecessary cooperation on BE and control

# deployment of seo edits means interference in frontend code instead of the normal situation where edits are made only in the administration, moreover the deployment itself requires work and knowledge that is not normally necessary at all, see the way of deploying meta information for social sites.

# it is not possible to use dynamic cutting of images on the server side as it is for example in the case of Timber/Twig where it is possible to cut freely according to the need without pre-generating n sizes, which then occupy nodes on the server

# the web has to run on a complex system with a separate backend-frontend which increases the long-term traffic costs. Which in normal cases can be solved by the most standard cheap hosting, which indeed increases the cost in short and long run of the project.

# updates require the cooperation of several entities at the same time [client, project manager, backend, frontend and server manager]

# in case of a change of structure or missing data, data generation via GQL sometimes leads to a total failure of the frontend, like in case of relationship to posts in trashcan..

# in the GQL frontend it is necessary to solve the search through the classic rest point, because GQL does not support the search endpoint affected by search plugins

# with the increased technological complexity, not only the requirement for more powerful machines is increasing, but also for documentation, which cannot be realistically done. One relies on the fact that when it comes to it, one simply digs through it – in other words you just write it all again rather than read somebody elses code.

# The headless approach is basically reinventing the wheel in many or close to all features the WordPress has tuned close to perfect over the decades. Enhanced with Composer and Timber and the like it is easy, readable, manageable and say fun to do.

Advantages of headless

# at first glance increased security due to the division into backend and frontend, however, even this can be easily circumvented and as a result shoot the right end

# You can feed more people in your team if you find client stupid enough who lets you choose this overhead for no reason.

# otherwise probably nothing… the advantages of headless start to play a role only in the case of applications where dynamic loading of some content is critically necessary for its own functionality – if.

What’s the right approach?

# create a serverside site from as much of it as possible and possibly upload side content via ASYNC or REST – if really needed. Fancy dynamic movements of pages can be solved on a javascript framework affecting the current html structure, or you can deploy a local minijavascript framework like Mithrill.js or any other small javascript framework for that matter.

Use candy only on the surface and not in the base.
Just like you take sweets after a good nutritious food and not a bag of candies for a lunch.