Decoupling Markup from APIs

Diving deeper into

Jamund Ferguson, senior engineer at PayPal, on using Jamstack in the enterprise

Interview
Can we decouple our APIs from our markup -- the sort of Jamstack idea -- and maybe quickly deploy our markup and static assets and then deal with the APIs separately?
Analyzed 3 sources

This is really a story about moving front end work out of the blast radius of a giant shared backend. At PayPal, changing a button, layout, or CSS file could mean redeploying a full Node.js app across hundreds of servers and data centers. Splitting static markup from APIs let teams ship page changes much faster, while avoiding server crashes that could take down active requests on a given instance.

  • In practice, decoupling means the user first downloads a prebuilt page from a CDN, then the page calls APIs for live data like identity, balances, or payments. That removes most page delivery from the app server, but keeps business logic in separate services.
  • The payoff is strongest on pages that are mostly the same for everyone, like marketing pages, docs, or simple flows such as paypal.me. Once every page is heavily personalized, the static shell pattern can create loading spinners unless some data is rendered closer to the user.
  • That is why enterprises often test Jamstack on narrow projects instead of rebuilding everything. Vercel and Netlify packaged the CDN, deploy pipeline, serverless functions, and routing into one fast workflow, while large companies on their own infrastructure often lacked the edge features needed for auth and security.

The direction of travel is toward hybrids that keep the fast deploy and front end simplicity of static sites, but add server rendering and edge functions where personalization matters. The winners will be the stacks that let a team update UI in minutes, while still handling auth, security, and per user data without forcing the page into a spinner filled second step.