Skip to main content

Why Headless Frontend is a Terrible Idea (Devil's Advocate)

"If it ain't broke, don't fix it." (And if you try to fix it, you'll probably break it).

The enthusiasm for React/Refine is understandable, but from a purely pragmatic and economic perspective, migrating OrderMGT to a Headless architecture presents huge risks and dubious business benefits. Here is why we shouldn't do it.

1. The Kendo MVC "Trap" (The Hidden Cost)​

Currently, Kendo UI for MVC does a huge and dirty job that we take for granted.

  • DataSourceRequest: When you filter a grid, Kendo sends a complex object that the backend automatically transforms into optimized SQL queries (via ToDataSourceResult).
  • The Problem: Moving to React, you lose this automation.
    • You have to manually rewrite JSON filter parsing on the API side.
    • You have to map these filters to Entity Framework.
    • Result: You will write hundreds of lines of "glue" code just to regain the same functionality you had for free yesterday.

2. The Hell of Duplicated Validation​

In MVC, you define rules once (DataAnnotations in the DTO) and get both Server and Client validation (via jQuery Validate Unobtrusive).

  • In Headless:
    • You have to write validation rules in the Frontend (Zod/Yup).
    • You have to maintain rules in the Backend (C#).
    • Risk: The two logics will diverge. A mandatory field on React might not be on the API, or vice versa, creating dirty data or frustrating errors for the user.

3. State Management and Distributed Complexity​

Today OrderMGT is stateful. It uses Session, TempData, and ViewBag to pass context.

  • Redirect: The controller decides where the user goes (RedirectToAction). It's simple.
  • React: The frontend must handle routing. If the backend wants to redirect the user after an action (e.g., "Approve Order -> Go to Dashboard"), it must send a special code that the frontend must interpret.
  • Race Conditions: Instead of a page that loads everything, you will have 10 asynchronous API calls. What happens if the "User Details" call fails but "Order Details" doesn't? Managing these partial states is exponentially more complex than the "all or nothing" of MVC.

4. Non-Existent ROI (Return on Investment) for Business​

End users (operators processing orders) don't care at all if there is React or jQuery underneath.

  • They care that the grid loads, that filters work, and that there are no bugs.
  • Cost: 9 months of development + 3 months of bug fixes (optimistic estimate).
  • Gain: Same interface (maybe a bit faster, but not guaranteed), but with new bugs introduced by the rewrite.
  • It is difficult to justify 1 man-year of budget to "have the same software as before, but written better".

5. The Human Factor (Knowledge Gap)​

The current team is expert in C# and MVC.

  • Introducing a React/TypeScript/Build Tools/Webpack/NPM stack requires a radical mindset shift.
  • It's not just about learning syntax, but learning the ecosystem, component lifecycle, hooks, and global state management.
  • In the meantime, who maintains the old MVC system while seniors learn React?

Conclusion​

Rewriting the frontend is a classic "Second System Effect". The complexity accumulated in years of bugfixes and patches in the old MVC code is underestimated. Throwing away Kendo MVC means throwing away years of stability. Instead of migrating to Headless, we should focus on Backend Refactoring (cleaning Controllers, moving logic to Services) whilst keeping MVC Views. It's less sexy, but infinitely safer and cheaper.