{"id":161,"date":"2026-06-06T21:46:58","date_gmt":"2026-06-06T21:46:58","guid":{"rendered":"https:\/\/softwareproduction.eu\/wordpress\/?p=161"},"modified":"2026-06-07T01:21:27","modified_gmt":"2026-06-07T01:21:27","slug":"the-legacy-problem-when-manual-synchronization-becomes-the-architecture","status":"publish","type":"post","link":"https:\/\/softwareproduction.eu\/?p=161","title":{"rendered":"The Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture"},"content":{"rendered":"\n

First in a series about migrating from legacy web architectures to a modern Nuxt 4 stack. The series covers architecture, code generation, performance, infrastructure, and the automation philosophy behind every decision.<\/em><\/p>\n\n\n\n

\n\n\n\n

The Starting Point: Architectures That Work \u2014 But Barely<\/h2>\n\n\n\n

Across multiple large, high-traffic, customer-facing web platforms \u2014 the kind where millions of visitors per year browse products, configure options, and complete purchases \u2014 two architectural patterns show up again and again:<\/p>\n\n\n\n

    \n
  1. Dual-rendering<\/strong>: ASP.NET MVC with Razor views and Vue.js components layered on top. The server renders HTML; the client re-renders parts of it.<\/li>\n
  2. SPA + BFF<\/strong>: A single-page application handles all rendering, calling a backend-for-frontend (BFF) layer for data. Types, REST clients, and mapping code are written by hand on both sides.<\/li>\n<\/ol>\n\n\n\n

    Both patterns work. Pages load, forms submit, orders go through. But both are collapsing under complexity that better code cannot fix. The problems are structural \u2014 rooted in manual synchronization between client and server code<\/strong> that compounds with every new feature.<\/p>\n\n\n\n

    This article walks through the patterns repeatedly seen in these systems, why they decay, and what finally pushes teams to break out.<\/p>\n\n\n\n

    \n\n\n\n

    The Architecture That Grew Sideways<\/h2>\n\n\n\n

    Variant A: Dual Rendering (Server HTML + Client JS)<\/h3>\n\n\n\n

    The most visible version of this problem follows a pattern that sounds sensible at first: server-side HTML rendering through Razor templates, with client-side interactivity layered in via Vue.js components<\/strong>.<\/p>\n\n\n\n

    The server renders page structure and static content. Vue components handle the dynamic pieces \u2014 a product configurator, a checkout form, an interactive filter. The two worlds are stitched together with data attributes, JSON blobs injected into the Razor HTML, and an ever-growing pile of initialization scripts.<\/p>\n\n\n\n

    Here is a simplified view of how a single page request flows through such a system:<\/p>\n\n\n\n

    flowchart TB\n    subgraph B[\"Browser\"]\n        Breq[\"User requests page\"]\n    end\n\n    subgraph S[\"ASP.NET MVC Server\"]\n        C[\"Controller\"]\n        VM[\"C# ViewModel\"]\n        RZ[\"Razor View\"]\n        HTML[\"Server-rendered HTML<br\/>+ embedded JSON blobs<br\/>+ &lt;script&gt; tags mounting Vue\"]\n    end\n\n    subgraph CS[\"Client-Side (Browser)\"]\n        PHTML[\"Step 1: Parse large HTML document\"]\n        PJS[\"Step 2: Download all JS bundles (no splitting)\"]\n        PJSON[\"Step 3: Parse JSON blobs from data attributes\"]\n        MOUNT[\"Step 4: Mount Vue components onto DOM nodes\"]\n        RERENDER[\"Step 5: Re-render with client-side data\"]\n        CLS[\"\u2192 Content jumps (CLS)\"]\n        TBT[\"\u2192 Slow interaction (TBT)\"]\n    end\n\n    Breq --> C --> VM --> RZ --> HTML\n    HTML --> PHTML --> PJS --> PJSON --> MOUNT --> RERENDER\n    RERENDER --> CLS\n    RERENDER --> TBT<\/pre>\n\n\n\n
    This is a dual-rendering architecture<\/strong>: the server renders HTML, and the client re-renders parts of it. Neither side has the full picture. The gap between what the server knows and what the client knows is where the bugs live.<\/p>\n\n\n\n
    Variant B: SPA + BFF (Client Renders Everything, Server Provides Data)<\/h3>\n\n\n\n
    The second variant looks more modern on the surface. A single-page application \u2014 React, Angular, or Vue \u2014 handles all rendering. The server exposes REST APIs (often through a BFF layer), and the client fetches data via HTTP.<\/p>\n\n\n\n
    There is no dual rendering, no hydration gap, no content flash. But the manual synchronization problem is identical<\/strong>:<\/p>\n\n\n\n
      \n
    • Every API endpoint needs a corresponding TypeScript interface on the client<\/li>\n
    • Every DTO in C# or Java needs a hand-written model in TypeScript<\/li>\n
    • Every REST client is bespoke: custom fetch wrappers, error handling, retry logic, response parsing<\/li>\n
    • Every new field or renamed property requires coordinated changes across both codebases<\/li>\n
    • Every API version bump triggers a manual update cascade through the frontend<\/li>\n<\/ul>\n\n\n\n
      flowchart LR\n    subgraph SPA[\"SPA (React\/Angular\/Vue)\"]\n        UI[\"Components\"]\n        TSM[\"Hand-written TS models\"]\n        RC[\"Hand-written REST clients\"]\n    end\n\n    subgraph BFF[\"BFF \/ Backend\"]\n        CTRL[\"Controllers\"]\n        DTO[\"DTOs \/ ViewModels\"]\n        SVC[\"Services\"]\n    end\n\n    UI --> TSM --> RC --> CTRL --> DTO --> SVC\n\n    classDef warn fill:#fff2e6,stroke:#e67e22,stroke-width:1px,color:#000;\n    TSM:::warn\n    RC:::warn\n    DTO:::warn<\/pre>\n\n\n\n
      The rendering is clean, but the data contract layer<\/strong> \u2014 the types, the clients, the mapping \u2014 is just as manual and just as fragile as in the dual-rendering case. A renamed field in the backend does not produce a compile error in the frontend. It produces a undefined<\/code> at runtime, caught by QA if you are lucky, or by a customer if you are not.<\/p>\n\n\n\n
      Teams in this position often generate TypeScript clients from OpenAPI specs, which helps. But it only covers the REST surface. If the frontend also consumes a headless CMS, a SOAP service, or multiple microservices with their own contracts, those sources still need manual type definitions. The problem is reduced but not eliminated \u2014 and the REST clients themselves still carry per-endpoint boilerplate: headers, auth tokens, error mapping, pagination handling, cache invalidation.<\/p>\n\n\n\n
      Both variants converge on the same core issue: manual synchronization of data contracts across a network boundary, at a scale where humans cannot keep up<\/strong>.<\/p>\n\n\n\n
      \n\n\n\n
      Five Problems That Compound<\/h2>\n\n\n\n
      The following problems manifest in both architectural variants, though the first (the hydration gap) is specific to dual-rendering systems. The remaining four apply equally to SPA + BFF architectures.<\/p>\n\n\n\n
      1. The Hydration Gap<\/h3>\n\n\n\n
      Modern SSR frameworks like Nuxt or Next.js solve the “server renders, client takes over” problem with hydration<\/strong>: the client receives the exact same component tree the server rendered and attaches<\/em> to it without re-rendering. The DOM stays stable. The user sees no flicker.<\/p>\n\n\n\n
      A dual-rendering architecture has no such mechanism. Vue components mount after<\/em> the server-rendered HTML is already visible. The browser shows the Razor output first \u2014 then, once JavaScript loads and runs, Vue replaces sections of the DOM with its own rendered output. The result is visible content jumps (Cumulative Layout Shift) and a page that feels slow even when the server responds quickly.<\/p>\n\n\n\n
      In practice, this often looks like a user landing on a product comparison page and seeing a static HTML shell for 1\u20132 seconds, followed by a jarring re-render as Vue components initialize and inject dynamic content. On mobile devices with slower CPUs, the effect is even worse.<\/p>\n\n\n\n
      sequenceDiagram\n    participant U as User\n    participant Br as Browser\n    participant S as ASP.NET MVC + Razor\n    participant JS as Vue JS Runtime\n\n    U->>Br: Navigate to product comparison page\n    Br->>S: HTTP GET \/products\/compare\n    S-->>Br: HTML (Razor-rendered shell<br\/>+ JSON blobs + script tags)\n    Br-->>U: Initial static HTML rendered<br\/>(*visible to user*)\n\n    par Network & CPU\n        Br->>JS: Download & parse JS bundles\n        JS->>Br: Initialize Vue runtime\n        JS->>Br: Mount Vue components<br\/>and re-render sections\n    end\n\n    Br-->>U: DOM updates cause<br\/>content jumps (CLS) and delay<br\/>before interactive (TBT)<\/pre>\n\n\n\n
      2. The Data Translation Layer<\/h3>\n\n\n\n
      In these architectures, every piece of data that must appear in both server-rendered HTML and client-side Vue components has to be manually translated<\/strong> between two type systems:<\/p>\n\n\n\n
      C# ViewModel (Server)          TypeScript Model (Client)\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500          \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nProductOfferModel.cs     \u2192     ProductOffer.ts\n  .PriceGross (decimal)           .priceGross (number)\n  .ProductName (string)           .productName (string)\n  .ValidFrom (DateTime)           .validFrom (string)\n  .IsDefault (bool)               .isDefault (boolean)<\/code><\/pre>\n\n\n\n
      For every backend data model, a developer has to:<\/p>\n\n\n\n
        \n
      1. Write a C# ViewModel class  <\/li>\n
      2. Write a corresponding TypeScript interface  <\/li>\n
      3. Write a mapping function that transforms the C# object into JSON  <\/li>\n
      4. Write another mapping function that deserializes it on the client side  <\/li>\n
      5. Keep all four in sync whenever any field changes  <\/li>\n<\/ol>\n\n\n\n
        This translation layer is tedious, but the real problem is that it creates constant bugs<\/strong>. A renamed field in C# silently breaks the client. A new enum value triggers a runtime error in JavaScript. A date format change causes forms to display the wrong values.<\/p>\n\n\n\n
        Some teams address this with OpenAPI<\/strong> (Swagger) by generating TypeScript clients from the backend’s REST API spec. For pure REST architectures, that is a solid approach. But it only covers the REST surface. If the frontend also consumes a headless CMS, a SOAP service, or server-rendered JSON blobs, those sources still need their own manual type definitions. OpenAPI reduces the problem; it does not eliminate it.<\/p>\n\n\n\n
        You end up with dozens of model pairs, each one a potential point of divergence.<\/p>\n\n\n\n
        flowchart LR\n    subgraph Server[\"Server (C#)\"]\n        VM[\"ViewModel class<br\/>(e.g., ProductOfferModel.cs)\"]\n        MAP_S[\"Mapping function:<br\/>C# \u2192 JSON\"]\n    end\n\n    subgraph Wire[\"Wire Format\"]\n        JSON[\"JSON payload\"]\n    end\n\n    subgraph Client[\"Client (TypeScript\/Vue)\"]\n        TSIF[\"TypeScript interface<br\/>(ProductOffer.ts)\"]\n        MAP_C[\"Mapping\/parsing function:<br\/>JSON \u2192 TS model\"]\n        VC[\"Vue component\"]\n    end\n\n    VM --> MAP_S --> JSON --> MAP_C --> TSIF --> VC\n\n    classDef warn fill:#fff2e6,stroke:#e67e22,stroke-width:1px,color:#000;\n    VM:::warn\n    TSIF:::warn\n    MAP_S:::warn\n    MAP_C:::warn<\/pre>\n\n\n\n
        3. No Unified API<\/h3>\n\n\n\n
        In legacy systems that grew organically, the frontend usually does not talk to a single API. Instead, it calls:<\/p>\n\n\n\n
          \n
        • REST endpoints for business logic and transactional operations  <\/li>\n
        • Direct headless CMS REST APIs for marketing or content pages  <\/li>\n
        • Server-rendered JSON blobs for other server-controlled content  <\/li>\n
        • Various cloud service endpoints for user data, feature flags, or personalization  <\/li>\n<\/ul>\n\n\n\n
          Each integration has its own error handling, retry logic, response format, and TypeScript types. There is no shared understanding of what “calling the backend” even means.<\/p>\n\n\n\n
          The result: every new feature requires figuring out which endpoints to call<\/strong>, in what order, and how to stitch the responses together. Frontend developers spend more time reading backend code than writing frontend code.<\/p>\n\n\n\n
          flowchart LR\n    FE[\"Frontend app<br\/>(Vue in Razor pages)\"]\n\n    subgraph APIs[\"Backend & Services\"]\n        REST[\"Business REST API\"]\n        CMS[\"Headless CMS REST API\"]\n        JSONB[\"Server-rendered JSON blobs\"]\n        CLOUD[\"Cloud services<br\/>(flags, personalization, auth, etc.)\"]\n    end\n\n    FE --> REST\n    FE --> CMS\n    FE --> JSONB\n    FE --> CLOUD<\/pre>\n\n\n\n
          4. Performance as an Afterthought<\/h3>\n\n\n\n
          Performance in these systems is rarely designed in \u2014 it is patched over with operational over-provisioning. The usual pattern looks like this:<\/p>\n\n\n\n
          Metric<\/th>Value<\/th><\/tr><\/thead>
          Median response time<\/strong> (homepage)<\/td>2,618 ms<\/td><\/tr>
          Error rate<\/strong> under normal load<\/td>3.91%<\/td><\/tr>
          JavaScript bundle size<\/strong><\/td>No code splitting \u2014 everything loaded upfront<\/td><\/tr>
          Infrastructure<\/strong><\/td>3\u00d7 P3v3 App Service instances (24 vCPU, 96 GB RAM)<\/td><\/tr>
          Scaling model<\/strong><\/td>Fixed \u2014 always on, always paying<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          A 2.6-second median response time is usually not a server problem \u2014 the C# backend is often reasonably fast. The problem is the rendering pipeline<\/strong>: large HTML pages, no code splitting, no lazy loading, uncompressed assets, and the sequential load-parse-mount-re-render cycle Vue must perform on every page view.<\/p>\n\n\n\n
          Throwing hardware at the problem \u2014 and three P3v3 instances is a lot<\/em> of compute \u2014 keeps the site alive, but it does not make it fast. And you pay the same at 3 AM with zero traffic as you do at noon during peak load.<\/p>\n\n\n\n
          5. Developer Experience Death by a Thousand Cuts<\/h3>\n\n\n\n
          Adding a new content section \u2014 say, a promotional banner with a countdown timer \u2014 can require touching six distinct layers<\/strong>:<\/p>\n\n\n\n
            \n
          1. C# TagHelper<\/strong> \u2014 to define how the server renders the banner’s outer HTML  <\/li>\n
          2. C# ViewComponent<\/strong> \u2014 to load data for the banner from a service  <\/li>\n
          3. CSHTML Razor View<\/strong> \u2014 to define the server-side template  <\/li>\n
          4. C# ViewModel<\/strong> \u2014 to define the data shape  <\/li>\n
          5. TypeScript Model<\/strong> \u2014 to mirror the data shape for the client  <\/li>\n
          6. Vue Component<\/strong> \u2014 to make the banner interactive (countdown logic)  <\/li>\n<\/ol>\n\n\n\n
            Six files, three languages, two rendering contexts. If the banner needs data from a headless CMS, add another REST client and another model conversion. If it needs form validation, add both C# server-side validation and JavaScript client-side validation \u2014 two implementations of the same rules.<\/p>\n\n\n\n
            In a SPA + BFF architecture, the first three layers disappear \u2014 but the remaining three do not. You still write the C# DTO, the TypeScript mirror, and the Vue component. You still write a REST client method. You still keep both sides in sync. The layer count drops from six to four, but the synchronization tax<\/strong> remains identical. Every field change still crosses the wire boundary by hand.<\/p>\n\n\n\n
            That is the cost of every feature. It compounds, and after a while developers start dreading change altogether.<\/p>\n\n\n\n
            flowchart TB\n    FEAT[\"Feature: Promotional banner<br\/>with countdown timer\"]\n\n    TAG[\"C# TagHelper\"]\n    VCMP[\"C# ViewComponent\"]\n    RAZOR[\"CSHTML Razor View\"]\n    VM[\"C# ViewModel\"]\n    TS[\"TypeScript model\"]\n    VUE[\"Vue component<br\/>(countdown logic)\"]\n\n    FEAT --> TAG\n    FEAT --> VCMP\n    FEAT --> RAZOR\n    FEAT --> VM\n    FEAT --> TS\n    FEAT --> VUE<\/pre>\n\n\n\n
            \n\n\n\n
            The Deeper Problem: Architectural Coupling Disguised as Separation<\/h2>\n\n\n\n
            The irony is that these architectures look<\/em> like they separate concerns. Server-side rendering is “separated” from client-side rendering. C# is “separated” from TypeScript. Razor views are “separated” from Vue components.<\/p>\n\n\n\n
            But the separation is structural, not functional. The layers remain tightly coupled through shared data contracts, rendering assumptions, and behavior expectations. Change one layer, and the ripple effects cross every boundary.<\/p>\n\n\n\n
            flowchart LR\n    subgraph Server[\"Server\"]\n        CS[\"C# Models\"]\n        RZ[\"Razor Views\"]\n    end\n\n    subgraph Client[\"Client\"]\n        VUE[\"Vue Components\"]\n    end\n\n    CS --> RZ\n    RZ --> VUE\n\n    subgraph Coupling[\"Shared assumptions \/ tight coupling\"]\n        FN[\"Field names must match\"]\n        DF[\"Date formats must match\"]\n        EV[\"Enum values must match\"]\n        NH[\"Null handling must match\"]\n    end\n\n    CS --- Coupling\n    RZ --- Coupling\n    VUE --- Coupling<\/pre>\n\n\n\n
            Real separation of concerns means a change in one area does not force changes in another. These architectures fail that test badly.<\/p>\n\n\n\n
            \n\n\n\n
            Breaking Out: The Architecture Used Instead<\/h2>\n\n\n\n
            The replacement architecture follows a different principle: one rendering engine, one type system, one unified API surface<\/strong>.<\/p>\n\n\n\n
            flowchart LR\n    subgraph Browser[\"Browser\"]\n        B[\"User\"]\n    end\n\n    subgraph Nuxt[\"Nuxt 4 (SSR)\"]\n        V3[\"Vue 3<br\/>Component Tree\"]\n        APClient[\"Apollo GraphQL Client\"]\n    end\n\n    subgraph Gateway[\"Apollo Server<br\/>(GraphQL Gateway)\"]\n    end\n\n    subgraph Backends[\"Backend Subgraphs\"]\n        CMS[\"CMS Subgraph\"]\n        DOTNET[\".NET Backend Subgraph\"]\n    end\n\n    B <-->|HTTP| Nuxt\n    Nuxt --> V3\n    V3 --> APClient\n    APClient --> Gateway\n    Gateway --> CMS\n    Gateway --> DOTNET<\/pre>\n\n\n\n
            The key shifts:<\/p>\n\n\n\n
              \n
            • Single rendering engine<\/strong>: Vue 3 renders on both server and client. The server produces HTML; the client hydrates the same component tree. No content jumps, no flickering.  <\/li>\n
            • Single API surface<\/strong>: A GraphQL gateway stitches together the headless CMS and the .NET backend into one schema. The frontend writes .graphql<\/code> query files; code generation produces fully typed TypeScript composables. No manual model translation.  <\/li>\n
            • Single type system<\/strong>: TypeScript everywhere, with types generated from the GraphQL schema. A renamed field in the backend breaks the TypeScript compiler \u2014 not the production website at 2 AM.  <\/li>\n<\/ul>\n\n\n\n
              sequenceDiagram\n    participant U as User (Browser)\n    participant N as Nuxt 4 SSR (Vue 3)\n    participant G as GraphQL Gateway\n    participant C as CMS Subgraph\n    participant D as .NET Subgraph\n\n    U->>N: HTTP GET \/page\n    N->>G: GraphQL query<br\/>(content + business data)\n    G->>C: Resolve CMS fields\n    C-->>G: CMS data\n    G->>D: Resolve .NET fields\n    D-->>G: .NET data\n    G-->>N: Unified GraphQL response\n    N-->>U: HTML (SSR) with embedded state\n    U->>N: Hydration request (client-side)\n    N-->>U: Interactive Vue app<br\/>(no re-render jump)<\/pre>\n\n\n\n
              \n\n\n\n
              What Gets Eliminated<\/h2>\n\n\n\n
              One of the most satisfying aspects of a migration like this is what you get to delete:<\/p>\n\n\n\n
              Layer<\/th>Old System<\/th>New System<\/th><\/tr><\/thead>
              C# ViewModels<\/strong><\/td>One per content type<\/td>\u274c Eliminated \u2014 types generated from GraphQL<\/td><\/tr>
              C# TagHelpers<\/strong><\/td>Custom HTML rendering<\/td>\u274c Eliminated \u2014 Vue components render everything<\/td><\/tr>
              CSHTML Razor Views<\/strong><\/td>Server-side templates<\/td>\u274c Eliminated \u2014 replaced by Vue SFC templates<\/td><\/tr>
              TypeScript model files<\/strong><\/td>Manual mirror of C# types<\/td>\u274c Eliminated \u2014 generated from schema<\/td><\/tr>
              REST client wrappers<\/strong><\/td>Per-endpoint fetch code<\/td>\u274c Eliminated \u2014 generated GraphQL composables<\/td><\/tr>
              JSON data injection<\/strong><\/td>Script tags with serialized models<\/td>\u274c Eliminated \u2014 SSR payload hydration<\/td><\/tr>
              Dual validation<\/strong><\/td>C# + JS validation rules<\/td>\u274c Eliminated \u2014 backend validation rules fetched at runtime<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              Every row in that table represents hundreds of lines of code and hundreds of potential bugs \u2014 gone, not refactored.<\/p>\n\n\n\n
              flowchart TB\n    subgraph Legacy[\"Legacy layers\"]\n        L1[\"C# ViewModels\"]\n        L2[\"TagHelpers\"]\n        L3[\"CSHTML Razor Views\"]\n        L4[\"Manual TS models\"]\n        L5[\"REST client wrappers\"]\n        L6[\"JSON data injection\"]\n        L7[\"Dual validation logic\"]\n    end\n\n    subgraph New[\"New stack\"]\n        GQL[\"GraphQL schema\"]\n        CGEN[\"Code generation<br\/>(types + composables)\"]\n        VUE3[\"Vue 3 components<br\/>(SSR + CSR)\"]\n    end\n\n    L1 -.removed.-> GQL\n    L2 -.removed.-> VUE3\n    L3 -.removed.-> VUE3\n    L4 -.removed.-> CGEN\n    L5 -.removed.-> CGEN\n    L6 -.removed.-> VUE3\n    L7 -.moved.-> GQL\n\n    GQL --> CGEN --> VUE3<\/pre>\n\n\n\n
              \n\n\n\n
              Measured Results<\/h2>\n\n\n\n
              Architecture decisions are opinions until you measure them. After migrating a legacy ASP.NET MVC + Razor + Vue system to Nuxt 4 with a GraphQL gateway and load testing against production-equivalent traffic patterns:<\/p>\n\n\n\n
              Metric<\/th>Legacy System<\/th>New System<\/th>Change<\/th><\/tr><\/thead>
              Median response time<\/strong><\/td>2,618 ms<\/td>165 ms<\/td>15.9\u00d7 faster<\/strong><\/td><\/tr>
              Error rate<\/strong> (1\u00d7 prod load)<\/td>3.91%<\/td>0.09%<\/td>97% lower<\/strong><\/td><\/tr>
              Max capacity<\/strong><\/td>~99 RPM<\/td>494+ RPM<\/td>5\u00d7 more<\/strong><\/td><\/tr>
              Infrastructure<\/strong><\/td>3\u00d7 P3v3 fixed (24 vCPU, 96 GB)<\/td>Auto-scaled containers<\/td>Elastic<\/strong><\/td><\/tr>
              Lighthouse Performance<\/strong><\/td>~50<\/td>97+ (mobile)<\/td>Near-perfect<\/strong><\/td><\/tr>
              Developer layers per feature<\/strong><\/td>6 files, 3 languages<\/td>1\u20132 files, 1 language<\/td>80% less<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              A 2.6-second median means the better half<\/em> of requests still took 2.6 seconds \u2014 the slower half took even longer. A 165 ms median means the page is rendered before a user can blink. At 5\u00d7 production load (494 RPM), the new system held that 165 ms median flat. It did not degrade.<\/p>\n\n\n\n
              flowchart LR\n    subgraph Legacy[\"Legacy System\"]\n        LRt[\"Median response: 2,618 ms\"]\n        LEr[\"Error rate: 3.91%\"]\n        LCap[\"Capacity: ~99 RPM\"]\n        LInfra[\"3\u00d7 P3v3, fixed\"]\n    end\n\n    subgraph New[\"New System\"]\n        NRt[\"Median response: 165 ms\"]\n        NEr[\"Error rate: 0.09%\"]\n        NCap[\"Capacity: 494+ RPM\"]\n        NInfra[\"Auto-scaled containers\"]\n    end\n\n    Legacy --> New<\/pre>\n\n\n\n
              \n\n\n\n
              Lessons Learned<\/h2>\n\n\n\n
              Manual synchronization is the real enemy<\/h3>\n\n\n\n
              Whether you have a dual-rendering architecture (server HTML + client re-render) or a clean SPA that calls a BFF, the core problem is the same: humans maintaining parallel data contracts across a network boundary<\/strong>. In the dual-rendering case, you additionally suffer from rendering conflicts and layout shifts. But the SPA + BFF case is no less painful in the long run \u2014 every endpoint still demands a hand-written TypeScript interface, a bespoke REST client, manual error handling, and a quiet prayer that nobody renamed a field on the other side.<\/p>\n\n\n\n
              If you are considering “progressive enhancement” by layering a JavaScript framework on top of server-rendered templates, be deliberate about the boundary. And if you already have a clean SPA but find yourself maintaining dozens of REST client wrappers and hand-mirrored types, recognize that the problem is not the rendering model \u2014 it is the absence of a single source of truth for data contracts<\/strong> that both sides can consume automatically.<\/p>\n\n\n\n
              Manual type translation does not scale<\/h3>\n\n\n\n
              Keeping C# models and TypeScript interfaces in sync is manageable at 5 types. At 50, it becomes a full-time job. At 100+, it is impossible without tooling. This applies equally whether those types back Razor views or REST endpoints consumed by a SPA \u2014 the synchronization burden is the same.<\/p>\n\n\n\n
              OpenAPI-based code generation bridges the gap for REST APIs, and many teams use it successfully. But it only covers the REST surface. If the frontend also consumes a headless CMS, a SOAP service, or multiple microservices with their own contracts, those sources still need manual type definitions. And even with OpenAPI generation, the REST clients themselves often carry per-endpoint boilerplate: custom headers, auth token injection, error mapping, pagination, and cache invalidation logic that gets copy-pasted across dozens of service wrappers.<\/p>\n\n\n\n
              A single schema that unifies all sources<\/strong> (for example, GraphQL) lets you generate types and clients<\/em> for everything from one place. That is the difference between reducing boilerplate and eliminating it.<\/p>\n\n\n\n
              You cannot buy your way out of a slow architecture<\/h3>\n\n\n\n
              Three P3v3 instances (24 vCPU, 96 GB RAM) running 24\/7 cannot match the performance of a few auto-scaled container replicas running a properly designed architecture. The response time improvement was not 10% or 20% \u2014 it was 15.9\u00d7<\/strong>. That kind of gain does not come from tuning. It comes from removing fundamental bottlenecks in how requests are processed.<\/p>\n\n\n\n
              Infrastructure cost follows architecture<\/h3>\n\n\n\n
              Legacy systems tend to rely on fixed, always-on compute that costs the same regardless of traffic. A well-designed replacement auto-scales: 5 replicas at idle, 15 under load. Fixed infrastructure is either over-provisioned \u2014 wasting money \u2014 or under-provisioned \u2014 dropping requests. Elastic infrastructure tracks actual demand.<\/p>\n\n\n\n
              \n\n\n\n
              What’s Next<\/h2>\n\n\n\n
              This article covered the what<\/em> and why<\/em>. The next article provides the architectural overview \u2014 the big picture that frames every subsequent deep dive:<\/p>\n\n\n\n
                \n
              • Article 2<\/strong>: The Target Architecture \u2014 A Bird’s-Eye View<\/em> \u2014 The four-container topology, the in-process GraphQL gateway, the code generation pipeline, and how every article in the series maps to the architecture.<\/li>\n
              • Article 3<\/strong>: GraphQL Schema Stitching \u2014 One API to Rule Them All<\/em> \u2014 How to unify multiple backend data sources into a single GraphQL gateway, including a custom @delegate<\/code> directive for cross-subgraph field resolution.  <\/li>\n
              • Article 4<\/strong>: The @delegate Directive Deep Dive<\/em> \u2014 Cross-subgraph field resolution with typed placeholders and formatters.  <\/li>\n
              • Article 5<\/strong>: GraphQL-Based Code Generation \u2014 Eliminating All Boilerplate<\/em> \u2014 How writing a .graphql<\/code> file generates a fully typed Vue composable with zero manual work.  <\/li>\n<\/ul>\n\n\n\n
                Each article focuses on a specific pattern and shows how automation can eliminate entire categories of manual work.<\/p>\n\n\n\n
                \n\n\n\n
                Munir Husseini is a software architect specializing in full-stack TypeScript, .NET, and cloud-native architectures.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"
                First in a series about migrating from legacy web architectures to a modern Nuxt 4 stack. The series covers architecture, code generation, performance, infrastructure, and the automation philosophy behind every decision. The Starting Point: Architectures That Work \u2014 But Barely Across multiple large, high-traffic, customer-facing web platforms \u2014 the kind where millions of visitors per […]<\/p>\n","protected":false},"author":1,"featured_media":210,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[5],"tags":[],"class_list":["post-161","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-advanced-web-app-with-nuxt-and-net"],"yoast_head":"\nThe Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture - Software Production<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/softwareproduction.eu\/?p=161\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"The Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture - Software Production\" \/>\n<meta property=\"og:description\" content=\"First in a series about migrating from legacy web architectures to a modern Nuxt 4 stack. The series covers architecture, code generation, performance, infrastructure, and the automation philosophy behind every decision. The Starting Point: Architectures That Work \u2014 But Barely Across multiple large, high-traffic, customer-facing web platforms \u2014 the kind where millions of visitors per […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/softwareproduction.eu\/?p=161\" \/>\n<meta property=\"og:site_name\" content=\"Software Production\" \/>\n<meta property=\"article:published_time\" content=\"2026-06-06T21:46:58+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-06-07T01:21:27+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/softwareproduction.eu\/wordpress\/wp-content\/uploads\/2026\/06\/01-the-legacy-problem.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1880\" \/>\n\t<meta property=\"og:image:height\" content=\"1253\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Munir Husseini\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Munir Husseini\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"17 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161\"},\"author\":{\"name\":\"Munir Husseini\",\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/#\\\/schema\\\/person\\\/fec48f54713e1bd117640fb9b748802f\"},\"headline\":\"The Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture\",\"datePublished\":\"2026-06-06T21:46:58+00:00\",\"dateModified\":\"2026-06-07T01:21:27+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161\"},\"wordCount\":2536,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/softwareproduction.eu\\\/wordpress\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/01-the-legacy-problem.jpg\",\"articleSection\":[\"Advanced Web App with Nuxt and .NET\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/softwareproduction.eu\\\/?p=161#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161\",\"url\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161\",\"name\":\"The Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture - Software Production\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/softwareproduction.eu\\\/wordpress\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/01-the-legacy-problem.jpg\",\"datePublished\":\"2026-06-06T21:46:58+00:00\",\"dateModified\":\"2026-06-07T01:21:27+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/softwareproduction.eu\\\/?p=161\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161#primaryimage\",\"url\":\"https:\\\/\\\/softwareproduction.eu\\\/wordpress\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/01-the-legacy-problem.jpg\",\"contentUrl\":\"https:\\\/\\\/softwareproduction.eu\\\/wordpress\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/01-the-legacy-problem.jpg\",\"width\":1880,\"height\":1253},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/?p=161#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/softwareproduction.eu\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"The Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/#website\",\"url\":\"https:\\\/\\\/softwareproduction.eu\\\/\",\"name\":\"Softwareproduction\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/softwareproduction.eu\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/#organization\",\"name\":\"Munir Husseini\",\"url\":\"https:\\\/\\\/softwareproduction.eu\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/softwareproduction.eu\\\/wordpress\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/softwareproduction-logo-32.png\",\"contentUrl\":\"https:\\\/\\\/softwareproduction.eu\\\/wordpress\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/softwareproduction-logo-32.png\",\"width\":32,\"height\":32,\"caption\":\"Munir Husseini\"},\"image\":{\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/#\\\/schema\\\/logo\\\/image\\\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/softwareproduction.eu\\\/#\\\/schema\\\/person\\\/fec48f54713e1bd117640fb9b748802f\",\"name\":\"Munir Husseini\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/b07845732d4d7bddfc43e608ae6662d564a14b35706dfae0c9610071d978f54e?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/b07845732d4d7bddfc43e608ae6662d564a14b35706dfae0c9610071d978f54e?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/b07845732d4d7bddfc43e608ae6662d564a14b35706dfae0c9610071d978f54e?s=96&d=mm&r=g\",\"caption\":\"Munir Husseini\"},\"sameAs\":[\"https:\\\/\\\/softwareproduction.eu\\\/\"],\"url\":\"https:\\\/\\\/softwareproduction.eu\\\/?author=1\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"The Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture - Software Production","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/softwareproduction.eu\/?p=161","og_locale":"en_US","og_type":"article","og_title":"The Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture - Software Production","og_description":"First in a series about migrating from legacy web architectures to a modern Nuxt 4 stack. The series covers architecture, code generation, performance, infrastructure, and the automation philosophy behind every decision. The Starting Point: Architectures That Work \u2014 But Barely Across multiple large, high-traffic, customer-facing web platforms \u2014 the kind where millions of visitors per […]","og_url":"https:\/\/softwareproduction.eu\/?p=161","og_site_name":"Software Production","article_published_time":"2026-06-06T21:46:58+00:00","article_modified_time":"2026-06-07T01:21:27+00:00","og_image":[{"width":1880,"height":1253,"url":"https:\/\/softwareproduction.eu\/wordpress\/wp-content\/uploads\/2026\/06\/01-the-legacy-problem.jpg","type":"image\/jpeg"}],"author":"Munir Husseini","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Munir Husseini","Est. reading time":"17 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/softwareproduction.eu\/?p=161#article","isPartOf":{"@id":"https:\/\/softwareproduction.eu\/?p=161"},"author":{"name":"Munir Husseini","@id":"https:\/\/softwareproduction.eu\/#\/schema\/person\/fec48f54713e1bd117640fb9b748802f"},"headline":"The Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture","datePublished":"2026-06-06T21:46:58+00:00","dateModified":"2026-06-07T01:21:27+00:00","mainEntityOfPage":{"@id":"https:\/\/softwareproduction.eu\/?p=161"},"wordCount":2536,"commentCount":0,"publisher":{"@id":"https:\/\/softwareproduction.eu\/#organization"},"image":{"@id":"https:\/\/softwareproduction.eu\/?p=161#primaryimage"},"thumbnailUrl":"https:\/\/softwareproduction.eu\/wordpress\/wp-content\/uploads\/2026\/06\/01-the-legacy-problem.jpg","articleSection":["Advanced Web App with Nuxt and .NET"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/softwareproduction.eu\/?p=161#respond"]}]},{"@type":"WebPage","@id":"https:\/\/softwareproduction.eu\/?p=161","url":"https:\/\/softwareproduction.eu\/?p=161","name":"The Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture - Software Production","isPartOf":{"@id":"https:\/\/softwareproduction.eu\/#website"},"primaryImageOfPage":{"@id":"https:\/\/softwareproduction.eu\/?p=161#primaryimage"},"image":{"@id":"https:\/\/softwareproduction.eu\/?p=161#primaryimage"},"thumbnailUrl":"https:\/\/softwareproduction.eu\/wordpress\/wp-content\/uploads\/2026\/06\/01-the-legacy-problem.jpg","datePublished":"2026-06-06T21:46:58+00:00","dateModified":"2026-06-07T01:21:27+00:00","breadcrumb":{"@id":"https:\/\/softwareproduction.eu\/?p=161#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/softwareproduction.eu\/?p=161"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/softwareproduction.eu\/?p=161#primaryimage","url":"https:\/\/softwareproduction.eu\/wordpress\/wp-content\/uploads\/2026\/06\/01-the-legacy-problem.jpg","contentUrl":"https:\/\/softwareproduction.eu\/wordpress\/wp-content\/uploads\/2026\/06\/01-the-legacy-problem.jpg","width":1880,"height":1253},{"@type":"BreadcrumbList","@id":"https:\/\/softwareproduction.eu\/?p=161#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/softwareproduction.eu\/"},{"@type":"ListItem","position":2,"name":"The Legacy Problem \u2014 When Manual Synchronization Becomes the Architecture"}]},{"@type":"WebSite","@id":"https:\/\/softwareproduction.eu\/#website","url":"https:\/\/softwareproduction.eu\/","name":"Softwareproduction","description":"","publisher":{"@id":"https:\/\/softwareproduction.eu\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/softwareproduction.eu\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/softwareproduction.eu\/#organization","name":"Munir Husseini","url":"https:\/\/softwareproduction.eu\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/softwareproduction.eu\/#\/schema\/logo\/image\/","url":"https:\/\/softwareproduction.eu\/wordpress\/wp-content\/uploads\/2026\/05\/softwareproduction-logo-32.png","contentUrl":"https:\/\/softwareproduction.eu\/wordpress\/wp-content\/uploads\/2026\/05\/softwareproduction-logo-32.png","width":32,"height":32,"caption":"Munir Husseini"},"image":{"@id":"https:\/\/softwareproduction.eu\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/softwareproduction.eu\/#\/schema\/person\/fec48f54713e1bd117640fb9b748802f","name":"Munir Husseini","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/b07845732d4d7bddfc43e608ae6662d564a14b35706dfae0c9610071d978f54e?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/b07845732d4d7bddfc43e608ae6662d564a14b35706dfae0c9610071d978f54e?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/b07845732d4d7bddfc43e608ae6662d564a14b35706dfae0c9610071d978f54e?s=96&d=mm&r=g","caption":"Munir Husseini"},"sameAs":["https:\/\/softwareproduction.eu\/"],"url":"https:\/\/softwareproduction.eu\/?author=1"}]}},"jetpack_featured_media_url":"https:\/\/softwareproduction.eu\/wordpress\/wp-content\/uploads\/2026\/06\/01-the-legacy-problem.jpg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=\/wp\/v2\/posts\/161","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=161"}],"version-history":[{"count":3,"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=\/wp\/v2\/posts\/161\/revisions"}],"predecessor-version":[{"id":211,"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=\/wp\/v2\/posts\/161\/revisions\/211"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=\/wp\/v2\/media\/210"}],"wp:attachment":[{"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=161"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=161"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/softwareproduction.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=161"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}