Modern Web Architectures: Part 2
SPAs, PWAs and API-first delivery. The second half of our tour through the choices that shape how a modern web product is built and shipped.
The short version
- SPAs give you app-like transitions and a clean split between view and backend, at the cost of SEO friction and a heavier first load.
- PWAs deliver installable, offline-capable experiences through the browser, sidestepping app stores and version fragmentation entirely.
- API-first is the precondition for all of it. Every architecture in this series collapses without a well-designed API underneath.
- The deciding factors are almost never technical elegance. They are SEO exposure, device breadth, team shape and time to market.
This continues the discussion we started in Part 1, where we covered microservices and serverless. Here we look at the three patterns that shape how a modern application is delivered to the people using it:
- Single-page applications
- Progressive web applications
- API-first design
Single-page applications
For years, the standard approach to making pages feel fast was caching layers — render the static parts of a page from cache and serve them quickly. Eventually a better idea emerged: load only the dynamic parts of a page via a request to the backend, and stop maintaining view caches at all. That freed the backend to concentrate on core logic and data caching rather than tightly coupled view caching.
What an SPA is
A single-page application dynamically rewrites a single page rather than fetching an entirely new document from the server on each interaction. The interface retains its structure throughout, which gives the application the feel of a native mobile app running inside a browser tab. The goal is faster transitions and continuity of state.
There is no shortage of libraries and frameworks for building them — React, Vue, Angular and others. Applications you use daily, including Gmail, Facebook and GitHub, are all SPAs.
In an SPA, the necessary HTML, CSS and JavaScript is either retrieved in a single request or loaded piecemeal as the user navigates.
Should everything be an SPA?
No. There are real trade-offs.
- SEO. Search ranking still leans heavily on crawlable links and markup, and SPAs are not naturally friendly to crawlers without additional work.
- Cost. Avoiding server-side rendering can raise development cost, because the skills for a rich client and a robust backend are not always found in the same people.
- First load. Shipping a substantial client library up front lengthens the initial page load, which is precisely the moment a new visitor is deciding whether to stay.
When an SPA is the right call
- Page load is slow because there are many components and some are much slower than others, so you want to render progressively.
- You want to decouple the view layer from the backend entirely.
- SaaS platforms, social networks and closed communities where SEO is not a primary concern.
Progressive web applications
PWAs were originally proposed by Google in 2015 and have drawn steady attention since. The pitch is that they combine the best of web and mobile: easier to deploy, faster to build, simpler to maintain.
What a PWA is
A PWA is application software delivered over the web using ordinary HTML, CSS and JavaScript, intended to run on any platform with a standards-compliant browser. It can work offline, receive push notifications, and sit on a phone’s home screen without ever passing through the Apple or Google stores.
What characterises a PWA
- Progressive — works for every user regardless of browser choice.
- Responsive — displays properly on desktop, mobile, tablet, kiosk and whatever comes next.
- Fast — the first load may take a moment, but everything after it should feel like a native offline app.
- Connectivity independent — usable on poor networks, degrading gracefully rather than failing.
- Safe — served over HTTPS, without exception.
- Discoverable — indexable by search engines.
- Installable — can be added to a device with a simple, obvious flow.
PWA versus a native mobile app
| Native app | PWA | |
|---|---|---|
| Distribution | Through the App Store or Play Store | Directly from the web, no gatekeeper |
| API versioning | Must stay backward compatible across many shipped versions | Everyone is on the latest build, so only the current API matters |
| Talent pool | Large and well established | Smaller; adoption is growing but still trails native |
API-first design
A user commonly interacts with one product through several interfaces — a mobile app, a web application, sometimes a desktop client. But how do the applications themselves communicate? They cannot use touch interfaces or read web components. They need APIs.
With IoT devices, wearables, connected vehicles and home automation all in the mix, the need for well-designed APIs so that different systems can exchange data and deliver something coherent has only grown.
Every architecture in this series depends on it. In microservices, a monolith is broken into small applications that talk to each other over APIs. PWAs rely on APIs for asynchronous communication. SPAs are optimised precisely by talking to an API rather than to a rendering server.
Beyond that, customers arrive on smartwatches, phones, tablets and laptops. Building a separate backend for each is both expensive and unmaintainable. A shared API is the only realistic way to support multiple form factors while giving users a connected, seamless experience.
In the API-first approach, you identify the core capabilities first and define the API before building any interface on top of it.
How API-first changes the way you work
Frontend and backend development stops being parallel and becomes genuinely synchronous. That requires real planning and an explicit agreement between the two teams to communicate whenever the contract shifts. The API must be self-descriptive, well documented and comprehensible to a developer who was not in the room when it was designed — which is what standards like REST and consistent JSON structures are for. Deployment changes too, because you now support multiple versions concurrently and must scale for traffic arriving from every interface at once.
Considerations before committing
- Cost. API-first is comparatively expensive. More people are involved and there is real overhead in defining and consuming the contract.
- Time to delivery. If you are racing an MVP to market to test an idea, a more traditional approach may get you the answer faster.
- Device breadth. If you will never support more than one device, and a responsive design covers your needs, an SPA or plain server-side rendering may be entirely sufficient.
A shortcut through the decision. Ask how much of your traffic must come from organic search, and how many distinct client surfaces you will realistically ship in two years. Those two answers eliminate most of the option space before anyone argues about frameworks.
Boolean Solutions experience with modern delivery
We build SPAs, PWAs and API-first backends for SaaS companies and startups, and we spend as much time advising teams out of these patterns as into them. A marketing site rebuilt as an SPA is a self-inflicted SEO wound; a PWA built for an audience that expects a store listing will simply not get installed.
If you want a second opinion on which delivery model suits your product and your audience, talk to us.
Further reading
- Progressive Web Apps — Google’s current guidance on building and shipping PWAs
- MDN: Progressive web apps — the vendor-neutral reference
- The OpenAPI Initiative — the de facto standard for describing an API contract
- Modern Web Architectures: Part 1 — microservices and serverless
Udit Mittal
Founder at Boolean Solutions. Twenty years of building and rescuing web, mobile and AI products for SaaS companies and startups — and writing down what actually worked.
Get in touch
