Skip to main content

Application Architecture

Description

Traditional Architecture

Server responds with HTML. If there is data to be loaded, then the server would get the data (e.g., through a query to the database), construct the HTML and then respond with it.

When data needs to be sent back to the server from the client, this can be done with:

  • HTML forms
  • JavaScript using the Fetch API
  • Declarative libraries built on top of the browser APIs

Some traits of this architecture include and are not limited to:

  • Server-side routing
  • Typically multi-page applications (MPAs), but can include both full page navigations or partial updates on the same page.
  • Caching of static or mostly static content
  • Application state primarily resides in the server
  • A sprinkling of client-side JavaScript to handle rich interactivity

This style of building applications encourages engineering teams to be structured as one unit. Engineers who are responsible for the entire application.

Examples

  • General: LAMP Stack and server side templating (e.g., Express.js server using Nunjucks templating, PHP)
  • Frameworks: Symfony, Laravel, Ruby on Rails, Spring, Django, Phoenix

JAMstack Architecture

Server (or CDN) responds with static HTML and the JavaScript on the page loads additional data from the server and renders that into HTML (if the data was not already HTML).

When data needs to be sent back to the server, it is typically done through JavaScript using the Fetch API.

Some traits of this architecture include and are not limited to:

  • Client-side routing
  • Typically single-page applications (SPAs) that emulate the loading of new pages through client-side application logic
  • Separate server application that produces JSON and a client application that consumes it to generate HTML in the user's browser
  • The initial HTML is typically an empty shell that is populated by the client-side application

This style of building applications encourages engineering teams to be structured as backend engineers and frontend engineers. The specialism allows teams to work independently but incurs a higher communication overhead to synchronise on building fullstack features.

Examples

  • Static site generators: Jekyll, 11ty
  • SPA frameworks: React with create-react-app or Vite
  • Data synchronisation: Fetch API, TanStack Query, GraphQL

Contemporary Architecture

This is an amalgamation of the Traditional and JAMstack architectures, and it has been popularized by JavaScript Metaframeworks, which are toolkits consisting of:

  • UI frameworks like React
  • Client-side router
  • Server-side framework
  • A bundler to generate an application artifact and infrastructure specifications

Therefore, it shares its characteristics from both depending on the specific blend of features. Some traits of this architecture include and are not limited to:

  • A combination of server-side routing and client-side routing
  • User experience characteristics of both SPAs and MPAs
  • The tools typically necessitate JavaScript on the client and the server to support isomorphic application logic [1]

This style of building applications encourages engineering teams to be structured as either backend engineers and fullstack engineers, or just fullstack engineers. The split depends on how much or how little teams embrace the framework's features to handle infrastructure on their behalf.

Examples

  • Frameworks that are more similar to JAMstack: Docusaurus, Gatsby, Next.js Pages Router
    • JAMstack architecture characteristics: Client-side data loading, client-side routing after initial page load, hydration step required to make the entire application a SPA again after initial load [1]
    • Traditional architecture characteristics: Generate initial HTML on the server, server-side routing for first page loads
  • Frameworks that are more similar to Traditional: Next.js App Router, Astro, Laravel with Inertia
    • JAMstack architecture characteristics: Client-side routing, hydration step required on just the interactive parts of the application
    • Traditional architecture characteristics: Server-side data loading, generate HTML on the server, handle routing on the server, stream pages to client, partial updates to page from the server

References & Further Reading

  1. Isomorphic JavaScript